Re: Error reporting, was Infinite look ahead required by C++?

Stephen Horne <sh006d3592@blueyonder.co.uk>
Wed, 17 Feb 2010 01:44:59 +0000

          From comp.compilers

Related articles
[2 earlier articles]
Re: Infinite look ahead required by C++? cfc@shell01.TheWorld.com (Chris F Clark) (2010-02-10)
Re: Infinite look ahead required by C++? idbaxter@semdesigns.com (Ira Baxter) (2010-02-13)
Re: Infinite look ahead required by C++? wclodius@los-alamos.net (2010-02-13)
Re: Error reporting, was Infinite look ahead required by C++? sh006d3592@blueyonder.co.uk (Stephen Horne) (2010-02-14)
Re: Error reporting, was Infinite look ahead required by C++? idbaxter@semdesigns.com (Ira Baxter) (2010-02-15)
Re: Error reporting, was Infinite look ahead required by C++? haberg_20080406@math.su.se (Hans Aberg) (2010-02-16)
Re: Error reporting, was Infinite look ahead required by C++? sh006d3592@blueyonder.co.uk (Stephen Horne) (2010-02-17)
Re: Error reporting, was Infinite look ahead required by C++? kkylheku@gmail.com (Kaz Kylheku) (2010-02-17)
Re: Error reporting, was Infinite look ahead required by C++? haberg_20080406@math.su.se (Hans Aberg) (2010-02-19)
Re: Error reporting, was Infinite look ahead required by C++? jdenny@clemson.edu (Joel E. Denny) (2010-02-19)
Re: Error reporting, was Infinite look ahead required by C++? cfc@shell01.TheWorld.com (Chris F Clark) (2010-02-19)
Re: Error reporting, was Infinite look ahead required by C++? cfc@shell01.TheWorld.com (Chris F Clark) (2010-02-19)
Re: Error reporting, was Infinite look ahead required by C++? jdenny@clemson.edu (Joel E. Denny) (2010-02-21)
[4 later articles]
| List of all articles for this month |
From: Stephen Horne <sh006d3592@blueyonder.co.uk>
Newsgroups: comp.compilers
Date: Wed, 17 Feb 2010 01:44:59 +0000
Organization: virginmedia.com
References: 10-02-024 10-02-029 10-02-047 10-02-055 10-02-062 10-02-064 10-02-070
Keywords: errors, parse
Posted-Date: 19 Feb 2010 01:45:24 EST

On Tue, 16 Feb 2010 18:37:39 +0100, Hans Aberg
<haberg_20080406@math.su.se> wrote:


>Stephen Horne wrote:
>> In LR(1), it is *easy* to give a message of the form "expected one of
>> <token list>, but <token> was found." - the set of possible next
>> tokens is part of the description of each state, and this can easily
>> be traced back to a set of productions (or else the parser could never
>> know when/what to reduce).
>>
>> Yacc and Bison don't support reporting errors in this form AFAIK, but
>> the tool isn't the same as the algorithm the tool uses.
>
>Those use LALR(1), though LR(1) support may be in the works for Bison,


Just making sure I haven't misunderstood...


LALR(1) is basically a minor variation of LR(1). The derivation of the
state model is a little different, but each state still has a set of
valid next tokens, used to choose between shifting and reducing.


>which compacts the states in such a way that when an error token
>appears, some extra reductions may take place before issuing the error.


This sounds like table compression modified by some form of
preprocessing of the state model, but it doesn't sound like an
inherent part of LALR, but rather an optimisation specific to Bison?



Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.