bison-patches
[Top][All Lists]
Advanced

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

Re: more %define/%code work


From: Joel E. Denny
Subject: Re: more %define/%code work
Date: Thu, 1 Mar 2007 13:24:33 -0500 (EST)

On Thu, 1 Mar 2007, Paolo Bonzini wrote:

> Joel E. Denny wrote:
> > I'm thinking of committing this.  Any comments?
> 
> I'm just curious what you need it for.  :-)

I imagine it's this part you're curious about:

+       Make it easy to share %define boolean variables between the front-end
+       and back-end.  Though not used yet, this will be useful in the future.

In general, I think we shouldn't keep creating new % directives when 
%define will work.  It requires less development to add a new %define 
variable.  We automatically pick up checking for redefinitions and unused 
variables (that is, variables that are unused *sometimes*).  Moreover, it 
creates a more consistent interface for the user.  I don't see why all of 
this should be limited to the variables used in the back-end.  In 
particular, the unused variable check can easily span both the front-end 
and back-end.

You're probably wondering if I have a specific use for this extension.  
Yes, and I've tested it, but it's offline work that I won't propose for 
Bison for a while.  I went ahead and proposed the %define extension so 
that it'll be ready to go if we encounter the same need sooner in 
mainstream Bison.

Here's a vague example of how the extension might be useful.  Imagine some 
flags to tweak parser table generation.  For example, it's interesting to 
see what happens when some of the parser table optimizations are removed.  
For certain kinds of parsers, such flags may be ignored either because 
they would break the parser algorithm or because they're required in order 
not to break the algorithm.  (Thus, the unused variable check.)  For 
certain kinds of parsers, the back-end would also need to be aware of such 
flags because they would alter the parsing algorithm.  It seems to me that 
%define handles all this well.

>From your point of view, I realize the extension is currently dead code.  
I suppose I could leave this part of the patch out.  However, again, I 
feel that it will be helpful to establish the concept in code now so that 
it's readily available for whoever ends up needing it first in mainstream 
Bison... or in any other offline work.

What do you think?




reply via email to

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