Re: inserting into tab.h, after %union

[Hans Aberg]

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

> > Wordings like:
> >
> > %code {code }
> > Other than semantic actions, this is probably the most common  
> > place you should
> > write
> > verbatim code for the parser implementation.
> >
> > Does not really tell what the command does.
>
> I intended it to help you remember the concept of the directive.   
> There
> are sentences afterwards that explain what it does at the low-level.

The rest did not help me either much. :-) I think a truly  
technologically dry description work be most effective, though  
clearly not as colorful. :-)

> > > > My intent was to get my programs working for current Bison, now  
> > > > that I can
> > > > use %define, but reality prevents me from attaining it.
> > >
> > > You can't download 2.3a for the %define extension?  Or you want  
> > > the %code,
> > > %requires, etc. directives from CVS?
> >
> > I have it, and got started. But "reality" refers to unrelated  
> > stuff preventing
> > me to work on it. Then, these discussions started, me being half- 
> > way trying to
> > get my project working with current Bison.
>
> Ah.  We can stop if you like.  :)

Among other things, I have afriend which is going up in space on  
Discovery, and I am on that mailing list. So if I do not respond much  
the next weeks, you know why.

> > To me, it looked as though "code file" just means a file  
> > containing code.
>
> Without keeping the Open Group spec in mind, yes, I can see that it  
> sounds
> that way.  It's the same point I made about "source file".  At the  
> moment,
> I can't think of any name that's unambiguous for this purpose.
>
> However, we're pretty far off topic now.  I just meant to point out  
> that,
> if you've read the Yacc spec, it seems logical that %code and %code- 
> top
> put code in the source/code/implementation/tab.c file.

I just wanted to point out that the name %code may not immediately  
give associations to the code file that Bison writes. Future will  
tell if there are better conventions.

> > Because I use a polymorphic class hierarchy, with a special Flex  
> > header setup,
> > and that was certainly not in the consideration of the work done  
> > with Bison so
> > far. So my worry is getting stuff that complicates the  
> > implementation of this
> > with standard Bison even further.
>
> If you find an example where the new directives will complicate  
> reasonable
> code, I'd appreciate a post about it.  However, it's not likely to  
> go far
> without an alternative proposal.

Before, I even made patch-posts, and somehow they were ignored.

I do not need anything dramatic even for the full Bison typing in  
cmopbination with C++ plyomymophic class hierarchy.

And I will post it, if I get my project up and working for latest  
standard (=unpatched) Bison.

  Hans Aberg