On Wed, 13 Sep 2006, Paul Eggert wrote:
> The
> old way is messy and complicated, but at least it's standardized and
> has well-known properties.
Do these well-known properties include the way Bison puts %{...%}
sometimes in the header? I don't know the history here.
> The proposed method considerably is more
> complicated than the old way
I don't agree. Maybe it's my presentation that complicated it. I'll
simplify by removing the replacements for #define YYSTYPE and #define
YYLTYPE and by abbreviating some of the directive names....
Any code related to the semantic type or to the location type goes in
%stype-code {...} or %ltype-code {...}, respectively. This includes
dependencies, #define YYSTYPE, and #define YYLTYPE. Any other code for
the header goes in %header {...}. Any other code for the code file goes
in %code {...}.
That seems pretty simple to me.
>, and its advantage is -- what?
The old subtle rules (such as the interaction between %union {...} and
%{...%}) don't need to be learned. Instead, you learn a few explicit
directives. You can easily control what goes in the header and what goes
in the code file. You can declare dependencies for a union field next to
the declaration for the union field. You can move and remove %union's
without affecting where your other code in other directives is generated.
> I'm trying to think about this more now because I ran into yet another
> problem with the current way -- it fails "make maintainer-check" due
> to yet another obscure problem with header ordering and YYSTYPE. I
> really haven't a clue as to why the test is the way it is, and I'm
> inclined to remove the test because I don't understand it. This is
> not a healthy situation.
_AT_CHECK_PRINTER_AND_DESTRUCTOR confused me too... and before I tried to
introduce %*-header. IMHO, that macro is to blame not %*-header.
Joel
