bison-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: push parser


From: Bob Rossi
Subject: Re: push parser
Date: Sat, 16 Dec 2006 17:15:05 -0500
User-agent: Mutt/1.5.12-2006-07-14

On Sat, Dec 16, 2006 at 05:04:42PM -0500, Joel E. Denny wrote:
> On Sat, 16 Dec 2006, Bob Rossi wrote:
> 
> > > BTW, after knowing all of this, if I were to write the patch, I would do
> > > it this way. I would leave the pure-parser option set to false. But I
> > > would write a new macro, b4_pure_or_push (or something), and replace all
> > > calls to b4_pure that are supposed to be b4_pure_or_push.
> 
> At the moment, that would be every call to b4_pure.  And b4_pure would 
> never be used outside of b4_pure_or_push.
> 
> Let's say we one day develop another kind of modifier like %push-parser.  
> I'll call it xyz and %xyz-parser.  Let's say we decide that all xyz 
> parsers must also be pure parsers.  Are we then going to write 
> b4_pure_or_push_or_xyz?  And then b4_pure_or_push_or_xyz_or_abc?
> 
> > > That would
> > > leave bison with the ability to perform all combinations of checks,
> > > which I don't think it can currently do now.
> 
> Assuming my patch, here are all 4 combinations, each with a check that 
> will be true iff that combination is true:
> 
>      pure   push   check
>   -----------------------------
>   1  false  false  !pure_parser
>   2  false  true   false
>   3  true   false  pure_parser && !push_parser
>   4  true   true   pure_parser && push_parser
> 
> So, assuming my patch, all checks are possible.  Notice that, since all 
> push parsers are pure, #2 is a fallacy.  We can check it and we'll get the 
> right answer, but what's the point?

Hmmm, ok. That does seem good.

Bob Rossi




reply via email to

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