But the dependence on the %union position is one of the key problems I was
trying to eliminate. I don't have time to examine your patch right now,
but, if I understand the explanation above, the only way to do the
equivalent of %end-header or %after-header is to have a %union. What if
the user doesn't have a %union?
You place your %{...%} or %header { ... } block *after the %%*, in the
grammar section. Java will not use %union in fact, but it needs to have
"%{...%}" after the %% to declare parser methods.
Also, I'd like to see this kind of grammar organization work:
%start-header { #include "type1.h" }
%union { type1 field1; }
%destructor { type1_destroy ($$); } <type1>
%start-header { #include "type2.h" }
%union { type2 field2; }
%destructor { type2_destroy ($$); } <type2>
This should be allowed in the definitions or rules section. If you change
%start-header to %header under your proposal, it won't work.
Yeah, I understand. But I wonder if it warrants the needed complexity.
In C, I put all my includes at the beginning of the file. It gives me a
quick way to see the interfaces I need in the file; I don't see the need
to scatter #include's here and there in a Bison source code?
I think it is a misfeature that %{...%} works differently when you're
using multiple-unions. But since we have to live with it, we'd better
make it coherent.
Thanks for your interest in this problem. Maybe you'd like to catch up
with our latest discussion starting here:
http://lists.gnu.org/archive/html/bison-patches/2006-09/msg00048.html
Already read, and was lost around the end of the thread. :-)
Paolo
