[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: proposal: simplify prologue alternatives into %code
From: |
Joel E. Denny |
Subject: |
Re: proposal: simplify prologue alternatives into %code |
Date: |
Thu, 4 Jan 2007 17:45:27 -0500 (EST) |
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.
Message not available
Re: proposal: simplify prologue alternatives into %code, Joel E. Denny, 2007/01/05