Re: proposal: simplify prologue alternatives into %code

[Joel E. Denny]

On Thu, 4 Jan 2007, Paolo Bonzini wrote:

> > I think having two forms for the same thing would be less consistent and
> > less simple than my proposal.  On the other hand, throwing away the default
> > form and having only the named form for it is inconsistent with the decision
> > tree I described above, and therefore I don't think it makes life any
> > simpler for the user.
> 
> I would say that having the named form and the default form reflects an
> attitude that "the newbie has a easy default, the expert has full control",
> and puts the 4 blocks on the same level for the expert.

To be clear, the expert has full control whether or not we support a name 
for the default.  I'm not sure why having the 4 blocks on the same level 
would be beneficial for the expert.  I think having two ways of writing 
the same thing would be confusing to both the expert and the newbie... 
especially the newbie.

> In particular, for
> the newbie that is learning the full syntax, it might help to understand that
> they are two pairs of blocks;

Maybe, but there were so many complaints about how %before-header, 
%start-header, %end-header, and %after-header were too low-level and thus 
confusing.  They promoted exactly that two-pairs view.

My current view is that there is the unqualified version to start with, 2 
more for the header ("requires" and "provides"), and the 1 ugly wart 
("top") that should be avoided when possible.  If you're not generating a 
header, my view instead is that there is the unqualified, "requires", and 
the ugly wart; forget "provides".

The more I've thought about it through all these discussions, the more I 
don't like the two-pairs view.  It associates "requires"/%start-header 
with the header.  Thus, if a user doesn't generate a header, it encourages 
him to put YYSTYPE/YYLTYPE dependencies in "top"/%before-header instead.  
First, for the sake of someone reading this code, "top" is not the 
appropriate semantic label for these dependencies; "requires" is.  
Second, when the user eventually decides he wants a header to make his 
parser more reusable, he'll then have to move much of his 
"top"/%before-header code to "requires"/%start-header.

That is, the user shouldn't think of "requires" as just a location in the 
header.  It's a location relative to YYSTYPE/YYLTYPE regardless of whether 
there's a header.  "provides" is the only qualifier that only makes sense 
with a header.  The two-pairs view is misleading.

> your syntax might suggest that the 3 named
> blocks are a different kind than the unnamed one.

In a sense, I mean to suggest that.  The user should usually try the 
unqualified version unless he actually needs to name the location.  It's 
sort of the top of the hierarchy.

> I don't have any strong opinion anyway.

As you can probably tell from my rambling above, I do.  After struggling 
through all the discussions in this area for so long, I see the 
unqualified/qualified concept as a nice improvement... especially for 
C/C++.  Of course, I could be wrong again, so I wish others would chime in 
here as well.

> Still, if you want to go with your proposed syntax, I think that the simplest
> thing to do (also considering the intuitiveness of using the feature in the
> skeletons) is to give the default "%code" an internal name, which is not
> documented;

In my implementation, it has a muscle name, yes.  I'm not sure how to do 
it without one anyway.  Oh, and it's no longer part of post_prologue, 
which I want to divorce from %code as much as possible.

By the way, thanks for the feedback.