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

Parsing of semicolon followed by binary operator is confusing #6961

Closed
vicuna opened this issue Aug 17, 2015 · 6 comments
Closed

Parsing of semicolon followed by binary operator is confusing #6961

vicuna opened this issue Aug 17, 2015 · 6 comments

Comments

@vicuna
Copy link

vicuna commented Aug 17, 2015

Original bug ID: 6961
Reporter: elnatan
Status: acknowledged (set by @damiendoligez on 2015-08-19T15:03:44Z)
Resolution: open
Priority: normal
Severity: minor
Version: 4.02.1
Target version: later
Category: lexing and parsing
Related to: #4627 #5936 #6327 #6828 #7193
Monitored by: @gasche @diml @hcarty

Bug description

The following two definitions are parsed differently. Is there a good justification for this?

let () =
let x =
let x = 5 in
let x = x + 1 in
ignore x; x
in
Format.printf "%d\n" x (* prints 6; the second 'let' extends past the semicolon *)
;;

let () =
let x =
let x = 5 in
let x = x + 1 in
x; * x
in
Format.printf "%d\n" x (* prints 30; the second 'let' ended at the semicolon *)
;;

To make things more confusing, replacing '*' with '+' in the second example causes the parsing to be the same as the 'ignore' case: the program prints 6, with the 'let' extending past the semicolon and '+' being interpreted as a unary operator (and the 'x;' leading to 'Warning 10: this expression should have type unit.').

(This example is somewhat contrived, but something like this is rather realistic when using monadic operators instead of '*' and '+'.)

@vicuna
Copy link
Author

vicuna commented Aug 18, 2015

Comment author: elnatan

I should add: I think the first parsing is the most natural, with the 'let' extending past the semicolon. My preference would be to make the latter parsing be a syntax error---I don't know why a binary operator should be allowed after a semicolon.

@vicuna
Copy link
Author

vicuna commented Aug 18, 2015

Comment author: nevor

Actually, it's the optional last silent semicolon that is kicking here. Sequences and records can end with a useless semicolon for cosmetics and to ease future code re-organisation :

let () =
let foo () =
do ();
do ();
in
foo ()

In your case when the parser hits "*", it reduces what it as parsed so far if it's an expression and, thanks to the optional semicolon, "let x = x + 1 in x;" is a valid expression.

@vicuna
Copy link
Author

vicuna commented Mar 8, 2016

Comment author: aalekseyev

I hit what looks like the same bug. [fun x -> y; >>= z] parses as [(fun x -> y) >>= z], which is very confusing.

@vicuna
Copy link
Author

vicuna commented Feb 24, 2017

Comment author: @damiendoligez

This would probably be solved by #7193 ( #522 )

@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 11, 2020
@gasche gasche removed the Stale label Jun 15, 2020
@gasche gasche reopened this Jun 15, 2020
@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.

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