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

Relax syntax for let binding in order to simplify type-constraint #5808

Closed
vicuna opened this issue Nov 5, 2012 · 7 comments
Closed

Relax syntax for let binding in order to simplify type-constraint #5808

vicuna opened this issue Nov 5, 2012 · 7 comments
Assignees

Comments

@vicuna
Copy link

vicuna commented Nov 5, 2012

Original bug ID: 5808
Reporter: @alainfrisch
Assigned to: @alainfrisch
Status: closed (set by @xavierleroy on 2015-12-11T18:25:28Z)
Resolution: fixed
Priority: normal
Severity: feature
Category: ~DO NOT USE (was: OCaml general)
Tags: patch
Monitored by: @jmeber

Bug description

The current syntax for let bindings makes it very easy to add a type constraint on a bound identifier:

let x : t = ...

Unfortunately, this does not work for an arbitrary pattern, and we need to use the parenthesized constraint pattern:

let (_ : int) = ...
let ({x; y} : t) = ...
let ((x as foo) : t) = ...

I attach a patch to accept the following syntax:

let p : t = ...

where p is a simple pattern (this includes in particular the cases above).

File attachments

@vicuna
Copy link
Author

vicuna commented Nov 6, 2012

Comment author: @gasche

There is a let_pattern production rule that would appear to have been designed for this purpose, but isn't actually used in the let_binding rule. It has the advantage of picking the proposer location for the constraint node, rather than ghost as in your patch.

I think we are paying the price of a small oversight of the OCaml syntax: the coercion syntax is not simple_expr COLON type but LPAREN expr COLON type RPAREN (and similarly for patterns), where parenthesis have a strict role that is not disambiguation -- the only thing parenthesis should be used for.

It would not be conservative to add simple_pattern COLON type as a rule for patterns, because (x, y : int) would then be ambiguous as meaning either (x,y) : int (interpretation of the current syntax) or x, (y : int) (interpretation of the nested simple_pattern rule with the current rule for commas).

I'm not fond of breaking the reassuring property that in the parsing of "let foo = ...", "foo" is exactly parsed as any pattern.

@vicuna
Copy link
Author

vicuna commented Nov 6, 2012

Comment author: @alainfrisch

I'm not fond of breaking the reassuring property that in the parsing of "let foo = ...", "foo" is exactly parsed as any pattern.

This is not the case, since

let x : t = ...

is already accepted, and so are:

let f x y = ...
let f x y : t = ...

In those cases, what's between "let" and "=" is not just a pattern. I simply propose to extend the subset of patterns for which:

let p : t = ...

is accepted (currently, only identifiers).

@vicuna
Copy link
Author

vicuna commented Nov 6, 2012

Comment author: @gasche

That's correct. Functions declarations have a specific syntax; I'm myself lobbying for a "fun p ... p : t ->" syntax.

I agree that the restriction to simple_pattern (atomic or parenthesized) rather than all patterns is a good idea. Otherwise the potential for confusion between the pattern-syntax and the function-syntax is a bit dangerous (let lazy x : t = ..., let F x : t = ...).

@vicuna
Copy link
Author

vicuna commented Nov 6, 2012

Comment author: @alainfrisch

I'm myself lobbying for a "fun p ... p : t ->" syntax.

I'm not against it, but do we agree that this is a different topic? (While we are at it, some time ago, I also proposed a patch to allow: let (f : t) x y z = .....)

@vicuna
Copy link
Author

vicuna commented Nov 7, 2012

Comment author: @garrigue

My understanding was that general patterns were not allowed there because of parsing conflicts.
How did you avoid it?

@vicuna
Copy link
Author

vicuna commented Nov 7, 2012

Comment author: @alainfrisch

I did not allow general patterns, only those recognized by the "simple_pattern" grammar entry. There was a conflict because the case of a single identifier is already recognized, so I've split the simple_pattern into two (introducing simple_pattern_not_ident, which was the old simple_pattern minus the ident case).

@vicuna
Copy link
Author

vicuna commented Dec 16, 2013

Comment author: @alainfrisch

Committed to trunk, rev 14362.

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

2 participants