|
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,
I'm envisioning the conflict actions we discussed always executing immediately.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.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
[Prev in Thread] | Current Thread | [Next in Thread] |