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 14:29:38 -0500 (EST)

On Wed, 4 Jan 2006, Frank Heckenbach wrote:

> Joel E. Denny wrote:
> 
> > Yikes.  Specifying a meaningless type is ugly.
> 
> Indeed, it looks ugly. OTOH, this seems a rather uncommon situation
> (using $-n is already ugly, IMHO -- is it POSIX conformant
> actually?), so I'm not convinced we need special effort in Bison to
> spare a few characters in such a particular situation. (But of
> course, it's not up to me to decide how much effort others put in
> it. ;-)

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?".  Moreover, 
this is a strong hint that the YYUSE_VAL mechanism will not be easy to 
evolve because bison can't easily parse it.

> > So maybe we should drop the YYUSE_VAL/USE macro idea and create some sort 
> > of construct that bison should parse.  This would be more flexible.
> > 
> > It looks strange at first glance, but the first thing that pops into my 
> > mind is:
> > 
> >   $<>1; $<>2; $<>3; $<>4; $<>5;
> 
> In this case, Bison could also warn if such a variable is actually
> used, e.g.:
> 
>   $<>1;
>   foo ($1);  /* or: foo ($<type>1); */

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.

Joel




reply via email to

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