[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: glr: include the created header
From: |
Akim Demaille |
Subject: |
Re: glr: include the created header |
Date: |
Mon, 19 Dec 2005 17:32:08 +0100 |
User-agent: |
Gnus/5.110004 (No Gnus v0.4) Emacs/21.4 (gnu/linux) |
>>> "Joel" == Joel E Denny <address@hidden> writes:
> On Sat, 3 Dec 2005, Akim Demaille wrote:
>> Le 3 déc. 05 à 02:44, Joel E. Denny a écrit :
>>
>>> Did you intend for b4_pre_prologue to appear in
>>> b4_shared_declarations? I didn't expect to see my prologues in my
>>> header file. This can lead to unexpected pollution of the
>>> namespace of the #includer, and it's inconsistent with yacc.c at
>>> least.
>>
>> Yes I did, because the pre-prologue is expected to define what
>> yystype needs, and the latter is export in the header file. Actually,
>> that's something I wish I could also change in yacc.c...
> I can see the logic in this feature, but I think it's a bit cryptic.
> Even more confusing since it's inconsistent with yacc.c.
I would have like yacc.c to follow this pattern too. I find this
logical.
>> If you don't want them to be exported, they should probably be
>> in the post-prologue. Is that ok with you?
> That's a problem because sometimes I either don't define %union or
> I define it with #define YYSTYPE (in a header file with its
> dependencies). In those cases, is there any way to avoid having
> all of my literal blocks dumped into the header file?
Bummer. You are right, in this case the pre-prologue should be the
post-prologue. Do you see a problem if that's implemented in Bison
that way?
> Why not add a %union-dependencies declaration? Its code could be
> placed in the shared dependencies. The pre-prologue and
> post-prologue could sit outside but in the usual sequence. This
> should be backward-compatible, easier to understand, and compatible
> with yacc.
I fear the introduction of zillions of %directives. And in this
precise case, a %directive followed by code, I would first like to
split the handling of {} in a second scanner.