help-bison
[Top][All Lists]
Advanced

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

Re: sticking custom meta informations to grammar rules


From: Christian Schoenebeck
Subject: Re: sticking custom meta informations to grammar rules
Date: Thu, 30 Jan 2014 15:15:43 +0100
User-agent: KMail/1.13.5 (Linux/2.6.32-5-amd64; KDE/4.4.5; x86_64; ; )

On Wednesday 29 January 2014 23:11:28 Hans Aberg wrote:
> It seems that your should use LR(1); see the Bison manual, sec. 5.8.1, "LR
> Table Construction". Bison by default uses LALR(1), which merges the
> states in such a way that when an error occurs, though no further tokens
> will be read, some additional reductions may be applied before an error is
> issued. 

Hmm, so far this was not the case. But I keep it mind, in case this problem 
occurs. Thanks!

> Using LR(1) guarantees that that will not happen; so you can check
> the lookahead tokens in the state, and that is also the set of valid
> completions. I do not know if LR(1) works with C++, though. And you may
> need to write some code in order to find the lookahead tokens; 

I already wrote that code, that is not the problem. My current code not only 
resolves the next expected tokens, but also already reduces them (if 
appropriate) to the more user friendly non-terminal symbols according to the 
grammar definition, depending on the state stack, position in the tree, etc. 
So it already walks up the possible tree branches and decides what to return 
as expected "possibilities" to the user.

So that is already working fine. However I want to fine tune it a bit more, 
for example I want to make it context dependent whether to reduce an expected 
possible non-terminal to a higher non-terminal. Because sometimes that would 
be useful for the user and sometimes it would be counter-productive for the 
user.

So that's why I was asking whether it is possible to associate custom (static) 
informations to individual grammar rules.

> you might
> want having this code integrated into the Bison distribution, so that the
> feature does not break with updates.

As far as I can see it, the semantics of the yyfoo tables generated by Bison 
have been constant over many, many years. At least I got that impression after 
reading the ChangeLog and comparing Bison versions. So I am not expecting my 
custom code (which is directly reading and interpreting the Bison generated 
yyfoo tables) to break with future Bison versions that soon.

Best regards,
Christian Schoenebeck



reply via email to

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