Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

minimal documentation on injectivity #7550

Closed
vicuna opened this issue Jun 4, 2017 · 10 comments
Closed

minimal documentation on injectivity #7550

vicuna opened this issue Jun 4, 2017 · 10 comments

Comments

@vicuna
Copy link

vicuna commented Jun 4, 2017

Original bug ID: 7550
Reporter: @Octachron
Status: acknowledged (set by @Octachron on 2017-07-11T19:44:17Z)
Resolution: open
Priority: low
Severity: feature
Category: documentation
Tags: manual, junior_job
Monitored by: @gasche

Bug description

Injectivity is never mentioned in the manual. Consequently, there are no explanation on why the "B" case cannot be refuted in

module M: sig type 'a t end = struct type 'a t = private T end
open M
type 'a s = A: int t s | B: float t s
let f:int t s -> int = function A -> 0 | _ -> .

whereas the apparently similar refutation case works fine:

module M: sig type 'a t = private T end = struct type 'a t = private T end
open M
type 'a s = A: int t s | B: float t s
let f:int t s -> int = function A -> 0

Adding a short example and explanation in the GADTs section of the language extension chapter would make the previous example less mysterious.

@isaacv-pl
Copy link

isaacv-pl commented Mar 20, 2020

Hi, I'm an Outreachy applicant. Could this be my first contribution?

@gasche
Copy link
Member

gasche commented Mar 20, 2020

Hi @nobrowser: yes it could, but I think that writing documentation on this point requires a good familiarity with the OCaml type system (it's a newcomer job because it does not require familiarity with the compiler implementation). If you are not familiar with GADTs or the behavior of the example given above, I would maybe recommend picking an easier task.

@nobrowser
Copy link
Contributor

Hmm. Has someone uttered my name? That is not an action one should take lightly! AAAARRRRGGHHHHH!

@gasche
Copy link
Member

gasche commented Mar 20, 2020

Indeed, I meant @notemaster; sorry @nobrowser :-)

@isaacv-pl
Copy link

Okay, I did spend a bit of time familiarizing myself with certain examples of GADT's and I have some background in Type theory but I'm not super solid on everything thats going here. I'll look at another job then but keep this one on the backburner. Thanks @gasche!

@Octachron
Copy link
Member

Octachron commented Mar 20, 2020

I have moved the issue to the advanced section of newcomer-jobs because it is the true that it requires a very specific skill set for a newcomer.

@anmolsahoo25
Copy link

anmolsahoo25 commented Jun 7, 2020

If I understand this correctly, this behavior is because in the first case the type is assumed to be non-injective, thus it unifies int t s and float t s whereas in the second case, the type is injective, thus int t s and float t s are now distinct and can be refuted. (Apologies for the imprecise wording, I guess, not too well-versed with OCaml's type theory)

@gasche
Copy link
Member

gasche commented Jun 14, 2020

Note: there is now a proposed PR, #9500, that introduces explicit annotations for injective type parameters (type !'a t= ...). It comes with minimal changes to the manual (see the current diff) that may interact with the request in this issue. Note that the new documentation is in the "type declaration" part of the reference manual, there would probably remain to mention injectivity explicitly in the GADT chapter.

@github-actions
Copy link

This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc.

@github-actions github-actions bot added the Stale label Jun 16, 2021
@Octachron Octachron removed the Stale label Jun 16, 2021
@github-actions
Copy link

github-actions bot commented Jul 1, 2022

This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc.

@github-actions github-actions bot added the Stale label Jul 1, 2022
@Octachron Octachron removed the Stale label Jul 1, 2022
@ocaml ocaml locked and limited conversation to collaborators Jan 26, 2023
@nojb nojb converted this issue into discussion #11942 Jan 26, 2023

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Projects
None yet
Development

No branches or pull requests

6 participants