Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0005808OCaml~DO NOT USE (was: OCaml general)public2012-11-05 14:592015-12-11 19:25
Assigned Tofrisch 
PrioritynormalSeverityfeatureReproducibilityhave not tried
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0005808: Relax syntax for let binding in order to simplify type-constraint
DescriptionThe 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).
Attached Filesdiff file icon patch_let.diff [^] (693 bytes) 2012-11-05 14:59 [Show Content]

- Relationships

-  Notes
gasche (developer)
2012-11-06 16:58
edited on: 2012-11-06 17:09

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.

frisch (developer)
2012-11-06 17:10

> 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).
gasche (developer)
2012-11-06 17:26
edited on: 2012-11-06 17:26

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 = ...).

frisch (developer)
2012-11-06 17:40

> 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 = .....)
garrigue (manager)
2012-11-07 09:34

My understanding was that general patterns were not allowed there because of parsing conflicts.
How did you avoid it?
frisch (developer)
2012-11-07 09:48

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).
frisch (developer)
2013-12-16 18:35

Committed to trunk, rev 14362.

- Issue History
Date Modified Username Field Change
2012-11-05 14:59 frisch New Issue
2012-11-05 14:59 frisch File Added: patch_let.diff
2012-11-06 16:58 gasche Note Added: 0008427
2012-11-06 17:09 gasche Note Edited: 0008427 View Revisions
2012-11-06 17:10 frisch Note Added: 0008428
2012-11-06 17:26 gasche Note Added: 0008429
2012-11-06 17:26 gasche Note Edited: 0008429 View Revisions
2012-11-06 17:40 frisch Note Added: 0008431
2012-11-07 09:34 garrigue Note Added: 0008436
2012-11-07 09:48 frisch Note Added: 0008437
2013-01-03 17:06 doligez Severity minor => feature
2013-01-03 17:06 doligez Status new => acknowledged
2013-12-16 13:32 doligez Tag Attached: patch
2013-12-16 18:35 frisch Note Added: 0010729
2013-12-16 18:36 frisch Status acknowledged => resolved
2013-12-16 18:36 frisch Resolution open => fixed
2013-12-16 18:36 frisch Assigned To => frisch
2015-12-11 19:25 xleroy Status resolved => closed
2017-02-23 16:36 doligez Category OCaml general => -OCaml general
2017-03-03 17:55 doligez Category -OCaml general => -(deprecated) general
2017-03-03 18:01 doligez Category -(deprecated) general => ~deprecated (was: OCaml general)
2017-03-06 17:04 doligez Category ~deprecated (was: OCaml general) => ~DO NOT USE (was: OCaml general)

Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker