Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

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

ocamlc/camlp4 should give better error messages for syntax errors #5068

Closed
vicuna opened this issue Jun 8, 2010 · 12 comments
Closed

ocamlc/camlp4 should give better error messages for syntax errors #5068

vicuna opened this issue Jun 8, 2010 · 12 comments

Comments

@vicuna
Copy link

vicuna commented Jun 8, 2010

Original bug ID: 5068
Reporter: @edwintorok
Status: acknowledged (set by @damiendoligez on 2011-06-01T21:31:56Z)
Resolution: open
Priority: normal
Severity: feature
Version: 3.11.2
Target version: later
Category: lexing and parsing
Has duplicate: #6244
Parent of: #3772 #5270 #5770 #6061 #6162 #6400 #6629 #7097 #7148
Monitored by: @hcarty

Bug description

ocamlc often just gives a "Syntax error", and even though it prints line/column range it is not immediately obvious what is wrong.
It would be useful if a more descriptive error message was given instead of a generic "Syntax error".

The ocaml toplevel, and camlp4 is better sometimes when it comes to syntax errors, however their messages aren't very user friendly either.

Here is an example:
module foo = struct
type t = int
end;;

$ ocamlc test.ml
File "test.ml", line 1, characters 7-10:
Error: Syntax error

An experienced ocaml programmer might know its due to the lowercase identifier, for others its not so clear what is wrong.

camlp4 is slightly better, at least it gives more detail about what is wrong,
however one can't ascertain that it is the lowercase first letter just from the message. The error location is wrong for camlp4 also:
$ camlp4o test.ml
File "test.ml", line 1, characters 0-6:
Parse error: "rec" or "type" or [a_UIDENT] expected after "module" (in [str_item]

Additional information

It would be nice if ocamlc/camlp4 could give a message like:
File "test.ml", line1, characters 7-10:
Parse error: "rec" or "type" or identifier with uppercase first letter expected after "module"

@vicuna
Copy link
Author

vicuna commented Jun 23, 2010

Comment author: @edwintorok

Here is an interesting idea on how to give better syntax errors, without having to edit the grammar parser (or its tables):
http://research.swtch.com/2010/01/generating-good-syntax-errors.html

Basically you give it an example of a syntax error and the message, and it determines which state your parser would reach for that syntax error, and use your error message there instead of the default "Syntax Error".

Perhaps this could be adapted to OCaml's parsers?

@vicuna
Copy link
Author

vicuna commented Jul 2, 2013

Comment author: @gasche

I recently became interested in the question of error messages as well -- partly because of Daniel Bünzli's feedback on http://gallium.inria.fr/blog/making-it-easier-for-beginners-to-learn-ocaml/ .

If nobody objects, I'm considering using this bug as a parent issue for sub-issues about confusing error messages. We could keep this one for discussion of general approaches to improve the situation, and report and handle specific issues on a case-by-case basis.

Given that the main parser (using by ocamlc/ocamlopt etc.) and Camlp{4,5} use completely different parser technology (L(AL)R for the compiler, LL(k) for Camlp4), the situation is very different -- in particular this is why Camlp{4,5} do a better job for now. I'm personally more interested in focusing on the compiler part, as it is what most users will see.

@vicuna
Copy link
Author

vicuna commented Aug 12, 2013

Comment author: nicolas_boulay

http://gallium.inria.fr/blog/making-it-easier-for-beginners-to-learn-ocaml/ give nice advice on ocaml tool.

I would add that a "endif" keyword will be great if related always to the inner most if-clause, in case of composed if-clause, it could be hard to read without a lot of parenthesis.

A build-in efficient hash will be great. List are nice, but not suffisant for large data set. Map functor make complex looking code.

@seantalts
Copy link

+1 - this has been one of the biggest obstacles to the team I work on learning ocaml.

Does anyone know where to track the efforts to replace the ocamlc parser with one written in Menhir with error messages?

@dbuenzli
Copy link
Contributor

dbuenzli commented Apr 3, 2019

@seantalts this is coming in the soon to be released 4.08. You can track the efforts that lead to it by following the references here.

@gasche
Copy link
Member

gasche commented Apr 3, 2019

(I see that Daniel just posted, but as complementary information:)

Does anyone know where to track the efforts to replace the ocamlc parser with one written in Menhir with error messages?

The ocamlc parser now uses Menhir (this will be first released as part of the upcoming 4.08 release), but there has been no concrete work on the syntax-error-messages part yet.

@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 15, 2020
@gasche gasche removed the Stale label May 15, 2020
@SteveBronder
Copy link

but there has been no concrete work on the syntax-error-messages part yet

Has there been any updates to this? Was recently trying to upgrade our project to 4.11.1 and ran into a syntax error on line 1 of a file which was just a comment

@damiendoligez
Copy link
Member

@gasche wanted to use menhir features to add better error messages, but I don't know how much progress has been made on this front.

@gasche
Copy link
Member

gasche commented Apr 30, 2021

Good question! There has been no further from me on this specific question since April 2019, but @fpottier has done a bit of preliminary work (10086, 10095), and @fpottier and @let-def have been working together on this topic in the last few months. I wish I could say more, but we see ourselves so rarely in these lockdown time that I don't have good information.

To say just a bit more: the work by @fpottier mentioned above goes toward giving a try to the current error-message approach in Menhir, for the OCaml grammar. Personally I don't think the current approach scales to OCaml in terms of maintainability of the error-message files, but @fpottier believes that it may work. Then their work with @let-def is around alternative approaches to specifying classes of failure states and generating semi-automatic (or automatic-assuming-user-annotations?) message, which would scale better, but requires upfront design and implementation work for them.

@XVilka
Copy link
Contributor

XVilka commented Sep 18, 2021

There is a label "error-messages", I suggest to assign it to this issue, it will finding all these error message improvements easier:
error-messages

@github-actions
Copy link

github-actions bot commented Oct 7, 2022

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 Oct 7, 2022
@Octachron Octachron removed the Stale label Oct 7, 2022
@ocaml ocaml locked and limited conversation to collaborators Jan 26, 2023
@nojb nojb converted this issue into discussion #11939 Jan 26, 2023

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Projects
None yet
Development

No branches or pull requests

9 participants