[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Joel E. Denny
Subject: Re: RFC: explicit empty right-hand side of a rule
Date: Sun, 3 Feb 2013 11:50:15 -0500 (EST)
User-agent: Alpine 2.00 (DEB 1167 2008-08-23)

On Sun, 3 Feb 2013, Akim Demaille wrote:

> > 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 '$'.

I understand how that looks tempting at first.  However, to summarize what 
I believe we're now agreeing upon....  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.

> 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 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[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.

Good point.

> 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?

> 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.  -Weverything and -Wno-everything seems sufficient.  
-Wdefault and -Wno-default are enough for computing the complement.

> 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 |.

reply via email to

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