"Joel E. Denny" <[EMAIL PROTECTED]> writes:
> That isn't equivalent yet because yours doesn't place those "header
> definitions that depend on y.tab.h" in the Bison-generated code file.
It shouldn't be hard to come up with something that's equivalent,
without departing from the traditional "yacc -d" model. Let me try to
derive it from my understanding of yacc -d. It works by translating
this:
%{ A %}
%union { B }
%{ C %}
%%
D
%%
E
to this:
A
[copy of y.tab.h]
C
[translation of grammar D into a parser]
E
where y.tab.h is derived from all the input (including (D)) and
defines YYSTYPE and YYLTYPE if they're not defined already.
Given this model, users that don't know about %start-header can simply
prepend "#include <parser.h>" to (C), where parser.h looks like this:
#include "y.tab.h"
[other definitions]
Other source-code modules simply #include <parser.h>.
y.tab.h is idempotent; it doesn't hurt to include it if it (or a copy
of it) is already included, so other modules can simply include
parser.h.
This mechanism is fairly simple, and it doesn't require the
%start-header/%end-header business that I am having so much trouble
following.
