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

"module rec" does not allow constraints on the first module #7884

Closed
vicuna opened this issue Dec 21, 2018 · 2 comments
Closed

"module rec" does not allow constraints on the first module #7884

vicuna opened this issue Dec 21, 2018 · 2 comments

Comments

@vicuna
Copy link

vicuna commented Dec 21, 2018

Original bug ID: 7884
Reporter: @yallop
Assigned to: @yallop
Status: resolved (set by @yallop on 2018-12-21T19:30:48Z)
Resolution: not a bug
Priority: normal
Severity: minor
Category: language features
Monitored by: @nojb

Bug description

This is allowed in a signature:

module rec X : T
and Y : T with type t = int

and this is allowed, too:

module rec X : T with type t = int [@@foo]
and Y : T

but this is currently rejected as a syntax error:

module rec X : T with type t = int
and Y : T

@vicuna
Copy link
Author

vicuna commented Dec 21, 2018

Comment author: @lpw25

This comes from the potential ambiguity with:

module rec X : T with type t = int
                   and type t = int

that is resolved in favour of shifting the and.

It can be avoided using parentheses:

module rec X : (T with type t = int)
       and Y : T

I think that avoiding the conflict isn't really possible in an LR(1) grammar because you'd need to know whether to shift or reduce the and without looking at the Y. Maybe you could extensively re-engineer the grammar so that the conflict was avoided, but I suspect its quite difficult to do so.

@vicuna
Copy link
Author

vicuna commented Dec 21, 2018

Comment author: @yallop

Ah, this is already noted in the manual!

Note that, in the specification case, the module-types must be parenthesized if they use the with mod-constraint construct.

It could be made a bit more precise, I suppose, by mentioning that the parentheses aren't needed on the last member in the group, but it hardly seems worth it.

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

1 participant