[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.
Re: Reductions during Bison error handling, Paul Hilfinger, 2002/05/10
Re: Reductions during Bison error handling, Paul Hilfinger, 2002/05/10
Re: Reductions during Bison error handling, Akim Demaille, 2002/05/20
- Re: Reductions during Bison error handling, Richard Stallman, 2002/05/20
- Re: Reductions during Bison error handling, Paul Hilfinger, 2002/05/20
- Re: Reductions during Bison error handling, Richard Stallman, 2002/05/21
- Re: Reductions during Bison error handling, Hans Aberg, 2002/05/21
- Re: Reductions during Bison error handling, Richard Stallman, 2002/05/23
- Re: Reductions during Bison error handling, Akim Demaille, 2002/05/24
- Re: Reductions during Bison error handling, Hans Aberg, 2002/05/24
Re: Reductions during Bison error handling, Paul Eggert, 2002/05/21
Re: Reductions during Bison error handling, Paul Hilfinger, 2002/05/21