Re: RFC: explicit empty right-hand side of a rule

[Akim Demaille]

Hi Joel,

I'm very happy to read from you!

Le 3 févr. 2013 à 06:59, "Joel E. Denny" <address@hidden> a écrit :

> On Wed, 30 Jan 2013, Akim Demaille wrote:
> 
>>> We have been toying with the introduction of a means to explicitly
>>> mark empty right-hand sides of rules.  It's on the explicit-empty
>>> branch on gnu.org's repository.  It allows to write
>>> 
>>>     exp: $empty { … }
>>> 
>>> and it's an exact synonym for
>>> 
>>>     exp: /* nothing. */ { … }
>>> 
> 
> Why $empty instead of %empty?  Normally in a Bison grammar file, "$" is a 
> prefix for semantic values, and "%" is a prefix for keywords.

That's right, but that's also how we name some special symbols:
$accept, $end, and @$1/@1 for mid-rule actions.  I agree though
that they are not keywords, but genuine symbols, so you are
right, %empty makes more sense.

I intend to use the same symbol in the various reports (foo.output, etc.).
Currently for "e: | e 'e'" we produce:

    0 $accept: e $end

    1 e: /* empty */
    2  | e 'e'

So it would read

    0 $accept: e $end

    1 e: %empty
    2  | e 'e'

mixing $ and %.  That was also a motivation for '$'.

>>> except that:
>>> 
>>> - bison does check that there is just $empty and nothing else
>>> - it will provide a warning to report implicit empty rhs
>>> - the various reports (e.g., foo.output, foo.dot) will use
>>> $empty (or maybe ε where possible) instead of nothing (or
>>> /* empty. */ as is done in some cases).
> 
> Makes sense, but I suggest the warning be once per grammar file, by 
> default.  Otherwise, it could be pretty noisy for existing grammar files.  
> Moreover, maybe Yacc mode should disable it altogether, by default.  
> (Sorry, I haven't looked at your branch to see what actually happens.)

I was planning to introduce a new warning category, -Wempty,
disabled by default.  I agree that --yacc should disable the
warning, but I have a problem with --yacc: that's how Automake
calls bison.  It does so so that we produce y.tab.[ch].  Yet
people are very frequently writing Bison grammars rather than
Yacc grammars, with tons of %bison-directives.  Bison _should_
warn against these %directives, yet it would be unproductive
as long as we have not cleared this Automake issue.

Maybe for the first release -Wall should not imply -Wempty,
to get some feedback first.  clang features -Weverything which
really enables every possible warning, contrary to -Wall
which enables, err, many warnings (as gcc does).

>>> There is one corner case whose treatment is currently unclear:
>>> mid-rule actions.  Currently
>>> 
>>>     exp: $empty { $$ = foo(); } $empty { $$ = bar(); }
>>> 
>>> is rejected, because I don't think accepting $empty in this situation
>>> actually helping.
>>> 
>>> /tmp/foo.y:2.6-11: error: $empty must be alone on the right-hand side of 
>>> the rule
>>> exp: $empty { $$ = foo(); } $empty { $$ = bar(); }
>>>     ^^^^^^
>>> /tmp/foo.y:2.29-34: error: $empty must be alone on the right-hand side of 
>>> the rule
>>> exp: $empty { $$ = foo(); } $empty { $$ = bar(); }
>>>                            ^^^^^^
> 
> I agree $empty is not helpful here.
> 
> At the beginning of a rule before a mid-rule action (such as the first 
> $empty in the above example), maybe $empty is even harmful.  It's already 
> easy to look at a mid-rule action (especially a long one) and mistakenly 
> believe you're reading the final action.  That effect is worsened if you 
> believe that a preceding $empty means the rule right-hand side is empty.

I agree.

> Adding a $empty after the final action in a rule would probably have a 
> strange effect.  That action would apparently become a mid-rule action, 
> and the new final action would apparently be the default $$=$1.
> 
> The only other place for $empty would be between actions (such as the 
> second $empty in the above example), but how often is it useful to have 
> two consecutive actions?  Even if two consecutive actions are somehow 
> useful, $empty just seems like clutter here.

And it makes it harder to visually find the n-th symbol.


If people really adopt [%$]empty and use it where appropriate, then
in an example such as

e: %empty { $$ = …; }
   e 'e'  { $$ = …; }

it is better to not accept %empty, as it would help to catch a clearly
missing "|".  It does seem clear that %empty should be only for
regular rules.