On Mon, 4 Dec 2006, Hans Aberg wrote: > On 4 Dec 2006, at 20:01, Joel E. Denny wrote: > > > Well, maybe I'm wasting your time, but I hope that helps you to get a > > better feel for the names than my original post did. > > I think you need to explain these much better, simply because wordings like > "this is the right place to put stuff like" is too unspecific to be useful.
In the specific email to which you're replying, I did not use that phrase. In the manual, I use a similar phrase to summarize the abstract concepts of the directives, but I also explain the exact functionality of the directives in great detail. Have you read the new manual section in CVS yet? > > Since tab.cpp is often referred to > > as the "code file", these names are actually quite easy to remember, in my > > opinion. > > I haven't heard the name "code file". I thought they were named "header" and > "source" in C/C++ lingo. In Open Group Yacc lingo, it's called the "code file": http://www.opengroup.org/onlinepubs/009695399/utilities/yacc.html I do not mean to say this is common C/C++ lingo. In C/C++ lingo, the term "source file" is ambiguous in my opinion. > > %requires and %provides insert code into tab.hpp before and after the > > union definition. Thus, %requires declares code that's required by the > > union. %provides declares code (containing declarations and definitions) > > to be provided to external modules. > > The problems with names like these, is that comon usage is to regulate > versioning. Nearly every word in English is overloaded, and we have to pick something. There's been no better suggestion so far in my opinion. > So I think names like "semantic-definition-preamble", "semantic- > definition-postamble", or something like that, will be better. :-) Those names are too specific. My previous email did not explain all potential uses of %requires and %provides because Jeff expressed a specific interest in the union. Those names are also low-level. While, this doesn't bother me too much, the other developers have objected to low-level names repeatedly in my previous proposals. Actually, I do like that the current directive names give some hint of the reason why the directives exist... rather than just hinting at their low-level functionality. _______________________________________________ help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison