[erlang-questions] Better error messages would be helpful

Anthony Ramine n.oxyde@REDACTED
Tue May 21 22:52:02 CEST 2013

I don't think there is any parsing technology that does all the things Clang do, and Clang is definitely the way to go with regard to compiler diagnostics. I would love to be wrong on this.

Anthony Ramine

Le 21 mai 2013 à 17:56, David Mercer a écrit :

> Richard A. O'Keefe wrote:
>>> 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?
>>>> 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.
> Is there a grammar language/parsing technology that you could use for this, or would it all pretty much be hand-roll-your-own?

More information about the erlang-questions mailing list