bison-patches
[Top][All Lists]
Advanced

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

Re: [SPAM] Re: [updated PATCH] %language declaration


From: Joel E. Denny
Subject: Re: [SPAM] Re: [updated PATCH] %language declaration
Date: Thu, 14 Dec 2006 17:28:55 -0500 (EST)

On Thu, 14 Dec 2006, Paolo Bonzini wrote:

> 
> > I was hoping that it would simplify your patch significantly, and then Paul
> > Eggert might be more inclined to review it before you commit it.  I find it
> > hard to understand a series of successively applied patches where a later
> > one significantly rewrites the logic of an earlier one.
> 
> I think such a patch would rewrite your output filename logic as much as it
> would rewrite the %language logic.  So... :-)

By "*your* output filename logic", are you referring specifically to one 
of my recent patches (which I wrote with the language.m4 idea in mind)?  
Or are you referring to Bison's existing logic for computing output file 
names?

> Can I commit the attached patch,

I'd rather Paul decided that.

> which implements the @value{VERSION} idea (a
> pretty good one!)?  I also rephrased the documentation to never mention the
> next version, and to document %language's case-insensitivity, and the
> comparison of %skeleton and %language where they really belong.

Thanks.

Other than the point about whether %language is experimental, I agree with 
Paul's suggestions.

I still think the C++ documentation should cross-reference the %language 
documentation.

The index documents Appendix A (which is sometimes called "Table of 
Symbols" and sometimes called "Bison Symbols") as:

  * Table of Symbols::  All the keywords of the Bison language are explained.

Thus, I think it should contain %language and %skeleton.  Why we duplicate 
so much documentation in "Bison Declaration Summary" (which your ChangeLog 
entry incorrectly calls "Directives"), I don't know.  Maybe Paul has a 
better sense of this.

Your ChangeLog entry says "Command line" where you apparently mean "Bison 
Options".

Is there a reason why @value{VERSION} handling in extexi needs to be 
specific to %require?  It might prove useful in other contexts.




reply via email to

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