[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: %push-* -> %define push_pull
From: |
Joel E. Denny |
Subject: |
Re: %push-* -> %define push_pull |
Date: |
Tue, 25 Sep 2007 04:46:48 -0400 (EDT) |
On Tue, 25 Sep 2007, Paolo Bonzini wrote:
>
> > %define api.push_pull "push|pull|both"
> > %define api.pure "true||false"
>
> Might be an idea; but what I dislike is the repetition between "push_pull" and
> the argument.
Yeah, that's been bugging me a little too. Can we think of a precise term
for push vs. pull? I did a little searching and didn't find any precedent
except just simply "push vs. pull". Thus, I chose push_pull. Maybe we
can establish something better. Parser polarity? Flow? Then we'd have
something like one of these:
%define polarity "push|pull|both"
%define flow "push|pull|both"
%define api.polarity "push|pull|both"
%define api.flow "push|pull|both"
Any other ideas?
I also thought about:
%define push
%define pull
I don't like this so much because push and pull are not as orthogonal as
this implies to me. For example, there is no yypstate and thus no
yypull_parse unless both push and pull parsing are requested.
> We could have "multi-word" options, like
>
> %define api "push pure"
> %define api "pull impure glr"
> %define api "push pull frobnicating"
>
> which makes error checking a tad more complicated, but should be doable if
> well abstracted with m4 (and thanks to the *-skel.m4 refactoring done as part
> of the Java port).
I had considered this too, and I agree it's doable, but I prefer the
clearer separation of orthogonal concerns that we have now. I'm also not
convinced the extra internal complication (however small) is worth it just
to avoid the name push_pull. But we shouldn't forget this as a
possibility.