MantisBT - OCaml
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0003772||OCaml||lexing and parsing||public||2005-08-26 09:00||2017-03-03 17:24|
|Assigned To|| |
|Product Version|| |
|Target Version||Fixed in Version|| |
|Summary||0003772: That #%$! syntax error two functions down|
|Description||Full_Name: Florian Hars|
Submission from: p54901fad.dip0.t-ipconnect.de (184.108.40.206)
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:
File "foo.ml", line 30, characters 0-3:
The binding before this might be incompletely terminated.
|Steps To Reproduce|
|Tags||No tags attached.|
|child of ||0005068||acknowledged || ||ocamlc/camlp4 should give better error messages for syntax errors |
|2005-11-18 10:13||administrator||New Issue|
|2006-08-24 02:52||n8gray||Note Added: 0003740|
|2013-07-02 16:22||gasche||Relationship added||child of 0005068|
|2016-12-12 16:46||lpw25||Note Added: 0016968|
|2017-02-23 16:36||doligez||Category||OCaml general => -OCaml general|
|2017-03-03 17:24||doligez||Category||-OCaml general => lexing and parsing|
|2017-03-03 17:24||doligez||Description Updated||bug_revision_view_page.php?rev_id=2937#r2937|
> 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
> 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.
> 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.
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
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".