[erlang-questions] Better error messages would be helpful

[Anthony Ramine]

Yes it is a roll-your-own parser.

-- 
Anthony Ramine

Le 22 mai 2013 à 00:51, David Mercer a écrit :

> 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?
>>> 
> 
>