bison-patches
[Top][All Lists]
Advanced

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

Re: glr: include the created header


From: Joel E. Denny
Subject: Re: glr: include the created header
Date: Thu, 15 Jun 2006 16:34:12 -0400 (EDT)

On Thu, 15 Jun 2006, Paul Eggert wrote:

> A nice solution but whew! it's kinda complicated when you step back
> and look at it.

It seemed simple at first... but then I got a little worried when I wrote 
the NEWS entry.  Looking at it again, I think I agree with you.

> Is there any reason one might want to put %header anywhere other than
> immediately before or after %union?

Not that I can think of.

> If not, another possibility is to
> extend the %union syntax to allow three operands, not one.

I don't like the semantics of this because the header prologue blocks 
aren't necessarily related to the union.  For example, in the header 
pre-prologue, I might just want to declare my own YYLTYPE.  I may not even 
have a %union.

> Or if
> that's too weird, the new %header syntax could be used _instead_ of
> %union, and could have three operands.

I've given this some thought, but the syntax seems a little unusual.

I think the real complication in my proposal is the dependence on the 
order of the declarations.  (I was trying to mimic %{...%}.)  Your 
proposal is trying to eliminate this problem, I think.

Maybe a simplier way is just to make header pre-prologue and post-prologue 
blocks explicit:

  %{
    /* Non-header pre-prologue block.  */
  %}
  %header-pre {
    /* Header pre-prologue block.  */
  }
  %union {
    int val;
  }
  %header-post {
    /* Header post-prologue block.  */
  }
  %{
    /* Non-header post-prologue block.  */
  %}
  
Since the declarations are explicit, you could rearrange the above as you 
please, and Bison would not need to track the order... except for 
non-header prologues as it already does.

Not only does this simplify the declarations, but it also makes them more 
flexible than my original proposal:

1. You don't need a %union to have post-prologues.  You can declare header 
post-prologue blocks explicitly.  You can declare an empty %header-pre or 
%header-post to separate non-header pre-prologue blocks from non-header 
post-prologue blocks.

2. One possible problem with my previous proposal was it disallowed 
%{...%} between %union's.  This might have been too restrictive for 
modular Bison grammar files with multiple concatenated %union's.

Since %header-pre and %header-post would not guarantee the generation of a 
header file, I'm wondering if they should be renamed.  Maybe %decls-pre 
and %decls-post?  That is, it's code placed before or after 
Bison-generated declarations like the enum, semantic type, and location 
type.

How does all this sound?

Joel




reply via email to

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