[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: too many warnings from Bison CVS for Pike
From: |
Hans Aberg |
Subject: |
Re: too many warnings from Bison CVS for Pike |
Date: |
Sun, 29 Jan 2006 19:34:46 +0100 |
On 29 Jan 2006, at 18:28, Joel E. Denny wrote:
My guess is that perhaps some option is needed. It is perhaps
though difficult
to motivate to C users to not have $$ = $1 always executed, if it
does not
cause any harm in doing it.
Beyond the C++ issue you raise, it seems that an action containing
nothing
but $$ = $2 ought to warn about an unused (typed) $1.
Unused token values are pretty common: just take
"if" A "then" B
Here, the token values of "if" and "then" will be unused in the rule
action. If this should work, I guess you are calling for a special
token type, say "void", and the warning should come if some non-void
$k isn't used. But this is a separate issue from the $$ = $1 one.
Explicit code is just cleaner. I doubt seriously that any user is
going
to abandon bison just because he can't bear to add $$ = $1 to his
actions.
Bison will even tell him exactly where to do so. If he complains that
he's unsure as to where the $$ = $1 was actually intended, that's
the very
reason he should have made it explicit in the first place.
Couldn't this be a --yacc issue? That is, --yacc would implement
whatever
the Open Group says. Without it, bison would be free to behave
well and
consistently for both C and C++: don't execute $$ = $1 before an
explicit
action.
If we're worried that some users won't want --yacc but will still
want an
implicit $$ = $1 for explicit actions, --yacc could accept options to
specify exactly which yacc features should be implemented. For
example:
--yacc=auto_lhs_value,filenames
--yacc=filenames
--yacc
where the last usage implies all yacc features. This approach
makes the
subtle hint that implicit $$ = $1 before explicit actions is simply
an old
and unfortunate idea.
When the code placement version of %define eventually appears, then
these issues can perhaps be resolved using it: In the old Bison
parser version, where $$ = $1 is always invoked, the code looks like
(in C pseudocode):
if (yylen >= 1)
$$ = $1;
switch (yytoken) {
default:
;
case ...
...
};
Now, if it should only be invoked for the rules that have a default
rule, the code is simply changed to:
switch (yytoken) {
default:
if (yylen >= 1)
$$ = $1;
case ...
...
};
thus moving it inside the switch statement.
Now, with a code placement in hand, one wants to be able to put code
at various place, including just ahead of the switch statement; call
the macro say 'pre-switch'. Then a fix under C for those that want $$
= $1 would a grammar '.y' file containing:
%define pre-switch { if (yylen >= 1) $$ = $1; }
...
One the actually will get two $$ = $1 performed in the default
actions, but that should not hurt under C.
One can also from the above see what may break when using a typed C++
parser, not using a union: Even if $$ and $1 have the same Bison
type, extracting the correct C++ type may involve applying certain
functions to $$ and $1. So the correct C++ statement may require
(depending on the C++ implementation model chosen) something like the
following (in C++ pseudocode):
convert(<type>, $$) = convert(<type>, $1);
Then one sees that now the default action actually varies with the
Bison type <type>. When comparing this with C and the 'union'
implementation, one can see that is hidden by the structure of the
'union'.
Anyway, since a code placement version will hopefully be implemented
eventually, it may be simplest to use it, before moving ahead with
various options, the latter will be more complicated.
Hans Aberg
- too many warnings from Bison CVS for Pike, Paul Eggert, 2006/01/28
- Re: too many warnings from Bison CVS for Pike, Hans Aberg, 2006/01/29
- Re: too many warnings from Bison CVS for Pike, Joel E. Denny, 2006/01/29
- Re: too many warnings from Bison CVS for Pike,
Hans Aberg <=
- Re: too many warnings from Bison CVS for Pike, Joel E. Denny, 2006/01/29
- Re: too many warnings from Bison CVS for Pike, Hans Aberg, 2006/01/29
- Re: too many warnings from Bison CVS for Pike, Joel E. Denny, 2006/01/29
- Re: too many warnings from Bison CVS for Pike, Hans Aberg, 2006/01/29
- Re: too many warnings from Bison CVS for Pike, Joel E. Denny, 2006/01/29
- Re: too many warnings from Bison CVS for Pike, Hans Aberg, 2006/01/29
- Re: too many warnings from Bison CVS for Pike, Joel E. Denny, 2006/01/29
- Re: too many warnings from Bison CVS for Pike, Hans Aberg, 2006/01/30
- Re: too many warnings from Bison CVS for Pike, Joel E. Denny, 2006/01/30
- Re: too many warnings from Bison CVS for Pike, Hans Aberg, 2006/01/30