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
_______________________________________________
help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison