[erlang-questions] Better error messages would be helpful

[David Mercer]

Isn't Clang and example of roll-your-own parser?  I thought it was developed to parse C and C only (and C derivatives).

Cheers,

DBM


> -----Original Message-----
> From: Anthony Ramine [mailto:n.oxyde@REDACTED]
> Sent: Tuesday, May 21, 2013 15:52
> To: David Mercer
> Cc: ok@REDACTED; 'Siraaj Khandkar'; 'Erlang-Questions Questions'
> Subject: Re: [erlang-questions] Better error messages would be helpful
> 
> 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?
> >> 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.
> >
> > Is there a grammar language/parsing technology that you could use for
> this, or would it all pretty much be hand-roll-your-own?
> >