help-bison
[Top][All Lists]
Advanced

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

Re: Reducing conflict: Was: Exceeded limits of %dprec/%merge?


From: Derek M Jones
Subject: Re: Reducing conflict: Was: Exceeded limits of %dprec/%merge?
Date: Sat, 20 May 2006 17:54:27 +0100
User-agent: Thunderbird 1.5 (Windows/20051201)

Joel,

On the subject of new features.  I have just been bitten (again)
by not being able to execute any actions in when multiple parse
stacks are in existence.  Having a way of specifying a non-deferred
action would solve a recurring problem of mine.
I'm envisioning the conflict actions we discussed always executing immediately.

Other than that, I have to say I'm currently not so interested in this. Maybe someone else is.

Well, just for kicks, what do you want your nondeferred actions to do?

Set a flag indicating that at least one parse has been found
and that no more input needs to be returned by yylex.

This behavior is connected to the issue discussed here:
http://lists.gnu.org/archive/html/help-bison/2006-04/msg00038.html

I thought that the problem had been solved (by pushing back the last
'unnecessarily' read token).  But the following input generates
a syntax error (I am parsing one statement/declaration at a time):

struct X Y;
if ( and so on

after the if token is read.

At least one of the parse stacks reduces to the penultimate
production after encountering the ; token, so it is known that at
least one parse will be found and that the lexer can now return
0 to indicate no more tokens.

In the above example all the parse stacks eventually get very upset
over that if token and I eventually end up with a syntax error :-(

--
Derek M. Jones                              tel: +44 (0) 1252 520 667
Knowledge Software Ltd                      mailto:address@hidden
Applications Standards Conformance Testing    http://www.knosof.co.uk




reply via email to

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