bison-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: prologue alternatives (was: Re: [GNU Bison 2.3] testsuite: 103 104 f


From: Joel E. Denny
Subject: Re: prologue alternatives (was: Re: [GNU Bison 2.3] testsuite: 103 104 failed)
Date: Wed, 13 Sep 2006 17:18:28 -0400 (EDT)

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]