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

[Akim Demaille]

Hi Joel,

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

> On Sun, 3 Feb 2013, Akim Demaille wrote:
> 
>> […] That was also a motivation for '$'.
> 
> I understand how that looks tempting at first.  However, to summarize what 
> I believe we're now agreeing upon….

I agree we agree :)

> In a grammar file, 
> keywords/declarations always start with % (and grammar symbol names never 
> start with $), so we should have %empty.  In the parser tables, $ is used 
> for special grammar symbols, and %empty is a declaration indicating a lack 
> of grammar symbols.

Right.

>> I was planning to introduce a new warning category, -Wempty,
>> disabled by default.
> 
> Maybe -Wempty-rule or -Wempty-rhs in case there's some other empty concept 
> one day?

I'd like to avoid abbreviations, which rules out rhs (ironically :).
I'd like to avoid unofficial vocabulary, and I was not aware "empty
rule" was admissible.  But a quick survey of the Internet (FWIW…)
seems to legitimate "empty rule" (Bison's documentation being one of
the places where it's already used).  So ok for -Wempty-rule!

I feel that using %empty should be all or nothing, so any occurrence
or %empty should enable -Wempty-rule, right?

>> Maybe for thet first release -Wall should not imply -Wempty,
>> to get some feedback first.
> 
> Leaving it off by default does seem right.  Does Bison currently enable 
> all (in the English sense of "all") warnings by default?

Bison's -Wall is really "all", i.e., what clang calls -Weverything.
Currently, the warnings (and whether they are enabled by default) are:

> Warning categories include:
>   `midrule-values'    unset or unused midrule values
>   `yacc'              incompatibilities with POSIX Yacc
>   `conflicts-sr'      S/R conflicts (enabled by default)
>   `conflicts-rr'      R/R conflicts (enabled by default)
>   `deprecated'        obsolete constructs
>   `precedence'        useless precedence and associativity
>   `other'             all other warnings (enabled by default)
>   `all'               all the warnings
>   `no-CATEGORY'       turn off warnings in CATEGORY
>   `none'              turn off all the warnings
>   `error[=CATEGORY]'  treat warnings as errors


>> clang features -Weverything which really enables every possible warning, 
>> contrary to -Wall which enables, err, many warnings (as gcc does).
> 
> Also, in gcc and clang, -Wall does not include the default warnings.  
> It's a separate category.  Quite a misnomer.  Maybe we should just not 
> have a -Wall.

We already have one.  I have tried to model Bison's diagnostic interface
to the one of gcc/clang.  In this regard, it would be weird not to support
-Wall, which is fairly traditional.

>  -Weverything and -Wno-everything seems sufficient.  
> -Wdefault and -Wno-default are enough for computing the complement.

You lost me :)

>> 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.
> 
> I think that's a great argument.  It shows how allowing %empty before a 
> mid-rule action works against what, in my opinion, is the practical 
> advantage of %empty: catching mistakes with |.

Yup.