Re: inserting into tab.h, after %union

[Joel E. Denny]

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.