bison-patches
[Top][All Lists]
Advanced

[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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]