[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Another error handling (Was: Reductions during Bison error handling)

From: Akim Demaille
Subject: Re: Another error handling (Was: Reductions during Bison error handling)
Date: 27 May 2002 08:35:28 +0200
User-agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Honest Recruiter)

>>>>> "Paul" == Paul Hilfinger <address@hidden> writes:

>> If we were to try to reimplement the somewhat more powerful scheme
>> that was (almost) implemented before, and to fix it, doesn't your
>> example demonstrate that we simply need to ``yyunlex'' the
>> lookahead when we find an error, and pretend the current lookahead
>> is error?  It seems to answer this scenario.  But maybe it's too
>> naive.

Paul> I don't quite understand what the "more powerful scheme" is
Paul> supposed to be.  That is, I don't know if allowing additional
Paul> reductions in the midst of error recovery is "more powerful" or
Paul> just "more confusing".

I should say that the current scheme _is_ more confusing, but in
another sense (see below).  I _absolutely_ agree the current scheme is
more predictable, and easier to understand.  But in some way, it is
less powerful than the previous one, because...

        Paul> The effect of the recent error-recovery changes to
        Paul> bison.simple is same as interpolating 'error' before the
        Paul> next token, EXCEPT that we never take a reduction with
        Paul> the error token as lookahead.

That's precisely what I meant.

Now, if there is an agreement that the original system once fixed is
no good, fine, there is no point in trying to resurect it under
another form.

But then (and this is what I'm referring to when I say that in a sense
it is more confusing than before), there are now uses of the error
token that can never be triggered.  Precisely when `error' is behind
nonterminals that cannot be produced.  Maybe a warning, or even
detecting this form of useless rule, would help users.

I'm probably just thinking aloud.  And if we really want a better
error recovery scheme, this one is probably not the one we want.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]