bug-bison
[Top][All Lists]
Advanced

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

Re: %destructor feedback


From: Joel E. Denny
Subject: Re: %destructor feedback
Date: Wed, 4 Jan 2006 15:27:05 -0500 (EST)

On Wed, 4 Jan 2006, Akim Demaille wrote:

> Le 4 janv. 06 ? 20:29, Joel E. Denny a ?crit :
> 
> > I don't see $<foo>3 as simply a waste of characters.  I see it as
> > misleading.  It begs the question, "What does `foo' mean?".
> 
> Well, I wrote foo, but I should have written the actual member name:
> $<val>3.  That's what is needed anyway in the action itself when
> assigning to $$ (well, $<val>$).

OK, but that's not enforced. Maybe I'm too concerned with forcing the user 
to "do the right thing".  It just bugs me that the text has no real 
meaning.

> > > > It looks strange at first glance, but the first thing that pops into my
> > > > mind is:
> > > > 
> > > >   $<>1; $<>2; $<>3; $<>4; $<>5;
> 
> Currently this is a syntax error: you are reminded there should be
> something there.

So it won't conflict with any current bison construct.

> > Yes, this is nice.  That is, if you have a complex action, you might
> > accidentally declare $<>1 and use $1 too.  That hints that there might be
> > something wrong with the logic in your action, so it's nice to have bison
> > warn you.  I don't think there would have been any easy way to detect this
> > mistake with YYUSE_VAL.  $<>1 is indeed more flexible.
> 
> I'm not convinced we need that much.  I can leave with $<val>3 :)

Even if no one is worried about it now, it's nice to know this sort of 
computation is possible should it become desireable.

At this point, it seems that no one (including me) has much affection for 
YYUSE_VAL.  For the time being, perhaps users can write their own USE 
macros as you do in the test cases.

If $<>n; or some other bison-parseable construct gains appeal, we could 
implement it as a new feature in 2.3 or later.

Joel

reply via email to

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