Skip to content
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

Constraints on type declarations can be of the form "typexpr = typexpr", not only "'ident = typexpr" #5987

Closed
vicuna opened this issue Apr 16, 2013 · 6 comments

Comments

@vicuna
Copy link

vicuna commented Apr 16, 2013

Original bug ID: 5987
Reporter: @alainfrisch
Status: confirmed (set by @damiendoligez on 2013-06-19T11:57:36Z)
Resolution: open
Priority: normal
Severity: minor
Category: documentation
Monitored by: @hcarty @garrigue

Bug description

The manual says:

type-constraint ::= constraint 'ident = typexpr

but the parser recognizes:

constrain:
core_type EQUAL core_type { $1, $3, symbol_rloc() }
;

(I wonder whether even the simpler form of constraints on type declarations is actually used...)

@vicuna
Copy link
Author

vicuna commented Apr 16, 2013

Comment author: @gasche

Yes, I think constraints have some use (besides backporting a soundness bug to old OCaml versions in the raging bugtracker discussion). I personally used them in conjunction with phantom object types in Macaque, to get a form of type-level records:

type 'phant binary_op = 'a t -> 'b t -> 'c t
  constraint 'a = < t : 'in_t; nul : 'n; .. >
  constraint 'b = < t : 'in_t; nul : 'n; .. >
  constraint 'c = < t : 'out_t; nul : 'n >
  constraint 'phant =
    < in_t : 'in_t; out_t : 'out_t; nul : 'n; a : 'a; b : 'b >

(Only the last constraint is really necessary, the others are here for readability)

@vicuna
Copy link
Author

vicuna commented Jun 19, 2013

Comment author: @damiendoligez

This appears to be deliberately documented that way. Should we change the documentation or restrict the parser?

@vicuna
Copy link
Author

vicuna commented Mar 16, 2017

Comment author: @garrigue

I see no gain in restricting the parser (being syntactically a variable does not mean anything semantically). So I suppose fixing the documentation is the way to go.

@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 May 15, 2020
@garrigue garrigue mentioned this issue May 15, 2020
@garrigue
Copy link
Contributor

Fix as suggested. Waiting for a review.

@gasche gasche closed this as completed May 15, 2020
@gasche
Copy link
Member

gasche commented May 15, 2020

Closed by merging #9568. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants