[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: %destructor feedback
From: |
Akim Demaille |
Subject: |
Re: %destructor feedback |
Date: |
Wed, 4 Jan 2006 20:45:30 +0100 |
Le 4 janv. 06 à 20:29, Joel E. Denny a écrit :
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?".
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>$).
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.
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.
I'm not convinced we need that much. I can leave with $<val>3 :)
- Re: %destructor feedback, (continued)
- Re: %destructor feedback, Joel E. Denny, 2006/01/03
- Re: %destructor feedback, Akim Demaille, 2006/01/03
- Re: %destructor feedback, Akim Demaille, 2006/01/04
- Re: %destructor feedback, Joel E. Denny, 2006/01/04
- Re: %destructor feedback, Frank Heckenbach, 2006/01/04
- Re: %destructor feedback, Joel E. Denny, 2006/01/04
- Re: %destructor feedback,
Akim Demaille <=
- Re: %destructor feedback, Joel E. Denny, 2006/01/04
- Re: %destructor feedback, Akim Demaille, 2006/01/05
- Re: %destructor feedback, Joel E. Denny, 2006/01/05
- Re: %destructor feedback, Paul Eggert, 2006/01/04
- Re: %destructor feedback, Akim Demaille, 2006/01/05