Re: inserting into tab.h, after %union

[Hans Aberg]

On 6 Dec 2006, at 10:58, Joel E. Denny wrote:

> > > Potentially, but I'm not inclined to complicate the existing  
> > > directives as
> > > we grope in the dark trying to accommodate future target  
> > > languages that we
> > > haven't even identified yet.
> >
> > This is what I am saying: you may already have done that by the  
> > current
> > commands.
>
> As far as these directives being complicated, I just don't think  
> they are.
> Neither did Akim Demaille (who initially proposed the names % 
> provides and
> %requires), Paul Eggert, Paolo Bonzini, and Pupeno when they first  
> heard
> of them.  Two months later, Paul said he had forgotten what the  
> directives
> meant, but he made no further comment.  Jeff Inman's discomfort seems
> quite mild, but I'd be glad to hear further discussion from him.

The problem is not that they are complicated, as they are rather  
straightforward, but eneded up with descriptions hard to understand  
what they do.

> I will say that %code-top is quite specific to C/C++ in my opinion.

So I would suggest to avoid language unification of code placements,  
until it is sure it is language independent. Don't know about naming.

> If
> anything should be converted to a %define, that would be it.

Better to make a new %code, I think. - will tell people what the  
command does, in addition to the potential parsing problem.

> Also, I must
> admit that I added it later without much comment from some of those  
> people
> I mentioned above.  Even in C/C++, I don't think it's very commonly
> needed, so most people can forget about it.

Especially in C++, there are number of places to put the code, and it  
is hard to judge the usefulness of it, without trying it up. So there  
is the need for simple skeletin file tweaks, without having to change  
the Bison grammar.

> > I propose to keep language specific, low-level names, until one  
> > can see what
> > features are language independent, and then succesively replace them.
>
> Well, the %before-header, %start-header, %end-header, and %after- 
> header
> directives were kind of like that before being renamed to the current
> directives.  However, before Java came up, we were already considering
> renaming them because Paul and Akim objected to their language- 
> specific,
> low-level names.  I guess you can't please everyone.  :)

When I tweaked Bison, I used names (internally in the tweak) like  
preamble for code (in the source file) before the union, and  
something else for code after it. This is still low level names,  
without being too language specific. There, one be reasonably sure,  
it is language independent. So therefore, the name "source-file"  
perhaps can be avoided. As for the header-file, other languages that  
C/C++ may not have it. So in that case, it might be best to bring out  
the name "header" in the commands, so the users know that it is for  
languages (or C/C++ uses) using a header. That is the principle I  
see, anyway.

> > > and the low-level details
> > > vary with the target language.
> >
> > So what happens if one uses a polymorphic hierarchy, with a  
> > different header
> > structure to accomodate for that?
> >
> > I mainly worried getting commands, hard to understand, conflicting  
> > or not
> > usable with the uses I may need.
>
> Sorry, I don't understand those two sentences.

Im the C++ polymorphic setup, I have a class 'object' maintaining a  
pointer to a class 'root' with a reference count. Other types are  
derived from the class 'root'. Special rules must be applied to  
extract these types, using either static_cast (possible if the type  
is known and the root class isn't derived as "virtual") or  
dynamic_cast. Now, I think that the Bison setup isn't even designed  
for handling redefinition of YYSTYPE. So I do not immediately see  
exactly what is needed, and how the current Bison commands will  
support that. It could be that they are simply of no use, and it must  
be resolved with skeleton tweaks and special code placement macros;  
but then it seems silly with special Bison commands for handling the  
implementation of the semantic type that cannot this.

But I guess, it can be changed later.

  Hans Aberg