[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: prologue alternatives
From: |
Joel E. Denny |
Subject: |
Re: prologue alternatives |
Date: |
Sat, 16 Sep 2006 17:31:54 -0400 (EDT) |
On Sat, 16 Sep 2006, Paul Eggert wrote:
> "Joel E. Denny" <address@hidden> 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
Let's say A defines YYLTYPE. Let's say I reorganize my grammar and move
or remove B. Now suddenly the compiler complains that I'm redefining
YYLTYPE. That makes no sense. What does %union have to do with YYLTYPE?
Let's say I have multiple B's:
%{ #include "type1.h" %}
%union { type1 field1; }
%destructor { type1_destroy ($$); } <field1>
%printer { type1_print (yyoutput, $$); } <field1>
%{ #include "type2.h" %}
%union { type2 field2; }
%destructor { type2_destroy ($$); } <field2>
%printer { type2_print (yyoutput, $$); } <field2>
The above code does not compile. How many undergraduates know why?
> 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
If they don't know about or like %start-header (or %type-code as we've
started calling it), they can use %{...%}. I'm not suggesting we break
Yacc-conformance by removing it.
> 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.
Users that don't want to think through these arcane declaration order
issues, %union and %{...%} interactions, and tedious #include solutions
can simply think about this:
1. Type code goes in %type-code {...}
2. Other header code goes in %header-code {...}
3. Other code goes in %code {...}
That is, the user tells Bison what each piece of code is for, and Bison
handles the gory details.
> This mechanism is fairly simple
I've used it, and I disagree. Bison should do the work. Not me.
>, and it doesn't require the
> %start-header/%end-header business that I am having so much trouble
> following.
Does calling them %type-code/%header-code help? %type-code is like A and
%code is like C... both regardless of whether there's a B. %header-code
is a new feature. Ignore it if you like.
- Re: prologue alternatives (was: Re: [GNU Bison 2.3] testsuite: 103 104 failed), Paul Eggert, 2006/09/13
- Re: prologue alternatives (was: Re: [GNU Bison 2.3] testsuite: 103 104 failed), Joel E. Denny, 2006/09/13
- Re: prologue alternatives, Paul Eggert, 2006/09/14
- Re: prologue alternatives, Joel E. Denny, 2006/09/14
- Re: prologue alternatives, Paul Eggert, 2006/09/15
- Re: prologue alternatives, Joel E. Denny, 2006/09/15
- Re: prologue alternatives, Paul Eggert, 2006/09/16
- Re: prologue alternatives, Joel E. Denny, 2006/09/16
- Re: prologue alternatives, Paul Eggert, 2006/09/16
- Re: prologue alternatives,
Joel E. Denny <=
- Re: prologue alternatives, Joel E. Denny, 2006/09/16
- Re: prologue alternatives, Paul Eggert, 2006/09/16
- Re: prologue alternatives, Joel E. Denny, 2006/09/16
- Re: prologue alternatives, Paul Eggert, 2006/09/17
- Re: prologue alternatives, Joel E. Denny, 2006/09/18
- Re: prologue alternatives, Paul Eggert, 2006/09/18
- Re: prologue alternatives, Joel E. Denny, 2006/09/18