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
Pattern type constraint in let expression parsed inconsistently #7758
Comments
Comment author: @Drup It would be nice to sort this out before the next release, as it messes up with ppx in a way that is difficult to take into account, even with ocaml-migrate-parsetree. If someone has a concrete proposition on how to make this cleaner, I'm ready to implement it. |
Comment author: @alainfrisch See https://blog.janestreet.com/plans-for-ocaml-408/, "https://blog.janestreet.com/plans-for-ocaml-408/":
FWIW, I'm not 100% convinced by the proposal, since it would mean treating very differently let (x1 : t), x2 = e1, e2 in ... from let (x1 : t) = x1 in ... which might be surprising for ppx authors and for users (in the first case, the annotation would not be propagated to the expression e1). An alternative would be to keep the annotations only in the pattern at the AST level, but somehow extract them (with a strategy to define) and apply them to the bound expression. |
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. |
I vote to close this. Here parentheses are relevant. |
@garrigue there are different things here. One is a special status of We can decide that we like or not the special typing discipline in the |
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. |
First, to clarify, originally the two syntaxes were already treated differently. let foo = (42 : int) in which is coherent with the handling in functions: let foo x : int = x+1 Now, for ppx's, wouldn't it be sufficient to disable the duplication of the type into the pattern when there is an extension? |
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. |
Another reason to have a distinct parsetree node for |
Since #12119, |
Original bug ID: 7758
Reporter: antron
Status: new
Resolution: open
Priority: normal
Severity: minor
Version: 4.06.1
Category: lexing and parsing
Monitored by: @nojb @Drup @ygrek
Bug description
The expression
(1)
let foo : int = 42 in ...
seems to get parsed as
while the expression
(2)
let (foo : int) = 42 in ...
which differs only in having parentheses, seems to get parsed as
I would have expected the second parse for both cases. The first parse can be problematic when using PPX, because the variable and expression may need to have different types. In particular, in
foo should have type int, and bar should have type int Lwt.t. See ocsigen/lwt#564.
Steps to reproduce
ocamlopt -dparsetree -c source.ml
Result is:
Additional information
Further complicating this in practice is that in 4.05.0, (1) is parsed as
i.e. the constraint is removed from the pattern and appears on the expression only.
The text was updated successfully, but these errors were encountered: