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

That #%$! syntax error two functions down #3772

Closed
vicuna opened this issue Aug 26, 2005 · 4 comments
Closed

That #%$! syntax error two functions down #3772

vicuna opened this issue Aug 26, 2005 · 4 comments

Comments

@vicuna
Copy link

vicuna commented Aug 26, 2005

Original bug ID: 3772
Reporter: administrator
Status: acknowledged
Resolution: open
Priority: normal
Severity: feature
Category: lexing and parsing
Child of: #5068
Monitored by: n8gray

Bug description

Full_Name: Florian Hars
Version: All
OS: Linux
Submission from: p54901fad.dip0.t-ipconnect.de (84.144.31.173)

If you happen to have a dangling semicolon at the end of a let binding, the
syntax error is reported after the end of the let binding following the
semicolon, at a completly error free function or even the end of the file.
I understand that this is just how the parser works, and if you've seen this a
few times, you know just what do to: scroll up to the end of the binding before
the binding that precedes the location of the syntax error. But it would still
be nice if the compiler would issue something like the "This '(' might be
unmatched" it issues if a closing paranthesis is missing (unless the missing
paranthesis is the last thing in a let binding, in which case you get a syntax
error at the beginning of the binding following the binding after the error).

The rule might be something like: if you are expecting an "in", but get a "let"
instead issue something like (if the dangling ; is in line 28)

File "foo.ml", line 80, characters 0-3:
Syntax error
File "foo.ml", line 30, characters 0-3:
The binding before this might be incompletely terminated.

@vicuna
Copy link
Author

vicuna commented Aug 26, 2005

Comment author: administrator

Full_Name: Florian Hars
Version: All

If you happen to have a dangling semicolon at the end of a let binding, the
syntax error is reported after the end of the let binding following the
semicolon, at a completly error free function or even the end of the file.

There is an easy solution: use ;; to terminate all your top-level phrases.

[...]

The rule might be something like: if you are expecting an "in", but get a
"let"
instead issue something like (if the dangling ; is in line 28)

File "foo.ml", line 80, characters 0-3:
Syntax error
File "foo.ml", line 30, characters 0-3:
The binding before this might be incompletely terminated.

This looks possible, but is it really worth the trouble? I'll file your report
in the "feature wish" category.

-- Damien

@vicuna
Copy link
Author

vicuna commented Aug 24, 2006

Comment author: n8gray

This looks possible, but is it really worth the trouble? I'll file your report
in the "feature wish" category.

I would argue that it's worth the trouble. One persistent complaint about OCaml made by newbies is that the error messages are obscure. This is a significant obstacle to learning the language. I know that I personally spent hours trying to debug an error like this when I started with OCaml. The ;; solution works, but in my experience it's quite rare for experienced programmers to actually use double-semis in production code. A student reading existing code for style tips would quickly start to omit them.

@vicuna
Copy link
Author

vicuna commented Dec 12, 2016

Comment author: @lpw25

This is harder fix than you might think. The simple rule of "if you are expecting an 'in', but get a 'let'" doesn't work because sometimes you are allowed to use an 'in' or a 'let'. For example:

let x = (); in
x

let x = (); let y = () in y

So any way to detect this error would need to know more of the parser's state than what is directly available when writing grammar rules. Or it would have to rewrite large parts of the expression grammar to separate out the different cases.

Perhaps if/when we switch to using Menhir as the parser generator we could use its more expressive error handling support to deal with this case. But until then this issue should probably be considered "suspended".

@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

1 participant