[erlang-questions] Better error messages would be helpful
Sun May 19 20:55:26 CEST 2013
You can in some cases alleviate the problem by adding explicit grammar rules which generate errors. It is not a good solution as you clutter up the syntax rules.
----- Original Message -----
> From: ok@REDACTED
> To: "Siraaj Khandkar" <siraaj@REDACTED>
> Cc: "Erlang-Questions Questions" <erlang-questions@REDACTED>
> Sent: Sunday, 19 May, 2013 1:41:32 AM
> Subject: Re: [erlang-questions] Better error messages would be helpful
> > On May 17, 2013, at 9:40 AM, David Mercer <dmercer@REDACTED>
> > wrote:
> >> Richard A. O'Keefe wrote:
> >>> Part of the problem is precisely the fact that the parser is
> >>> written in
> >>> Yecc.
> >> Back in the day, I'd have known the answer to this, but I figure
> >> some of
> >> you are more knowledgeable than I ever was: What parsing
> >> technology
> >> besides hand-rolled would produce better error messages? ANTLR?
> >> Parsec? PEG?
> > Menhir
> > http://gallium.inria.fr/~fpottier/menhir/
> Menhir is definitely interesting, and if I had experienced anything
> other than extreme frustration with Godi, I would have liked to
> try it. But judging from section 8 of the Menhir manual, a
> Menhir-built parser would be no better than a Yecc-built one here.
> It might even be worse: the manual says that the current lookahead
> token is *replaced* by an ERROR token as part of recovery, and in
> the example we are discussing, the token in question is ")" and it
> is correct, and should be retained. What is more, the Menhir manual
> is quite explicit that error detection may be deferred.
> What the user needs in cases like this is the information that
> an earlier token (fun) caused the parser to be looking for a
> particular token (end) but it encountered a closer (right paren)
> before finding it. Something basically top-down should have an
> easier time of it.
> erlang-questions mailing list
More information about the erlang-questions