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:[EMAIL PROTECTED]
Applications Standards Conformance Testing http://www.knosof.co.uk
_______________________________________________
help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison