Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!news.glorb.com!border1.nntp.dca1.giganews.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!news.iecc.com!.POSTED!nerds-end
From: Kaz Kylheku <kaz@kylheku.com>
Newsgroups: comp.compilers
Subject: Re: Grammar with low-precedence postfix operator?
Date: Wed, 11 Feb 2015 02:19:24 +0000 (UTC)
Organization: Aioe.org NNTP Server
Lines: 71
Sender: news@iecc.com
Approved: comp.compilers@iecc.com
Message-ID: <15-02-025@comp.compilers>
References: <15-02-006@comp.compilers> <15-02-014@comp.compilers> <15-02-024@comp.compilers>
NNTP-Posting-Host: news.iecc.com
X-Trace: miucha.iecc.com 1423665654 67026 2001:470:1f07:1126:0:676f:7373:6970 (11 Feb 2015 14:40:54 GMT)
X-Complaints-To: abuse@iecc.com
NNTP-Posting-Date: Wed, 11 Feb 2015 14:40:54 +0000 (UTC)
Keywords: parse, errors
Posted-Date: 11 Feb 2015 09:40:54 EST
X-submission-address: compilers@iecc.com
X-moderator-address: compilers-request@iecc.com
X-FAQ-and-archives: http://compilers.iecc.com
Xref: csiph.com comp.compilers:1527

On 2015-02-10, Joe keane <jgk@panix.com> wrote:
> Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>For your example involving ^ and ++, I think that one should use
>>parentheses explicitly in most cases, e.g. (a^b)++^c or a^(b++)^c.
>>You can leave away the parentheses if there is no ambiguity, as in
>>your 2++^3, but that's not straightforward to express in BNF.
>
> gcc does something like this
>
> You can say:
>
> 	if (x & y == 0)
>
> probable error, warn or reject
>
> 	if ((x & y) == 0)
>
> OK
>
> 	if (x & (y == 0))
>
> OK, if that's what you want
>
> I don't know how it is implemented.

You can implement it by adding a boolean attribute to a parse tree
node which indicates whether it had been parenthesized.

Fictitious Yacc production with semantic rule:

   expr : '(' expr ')'  { $2.parenthesized = 1;
                          $$ = $2; }


So now inside a rule like this:

  expr : expr '&' expr

you can do:

   { prec_paren_check($1, PREC_MUL);
     prec_paren_check($3, PREC_MUL);
     ... }


Where and_prec_paren_check looks something like this:

   void prec_parent_check(ast_node *node, int prec)
   {
      if (node->prec <= prec && !node->parenthesized)
        issue_warning("suggest parentheses around %N", node);
   }

The idea here is this:

1. Obviously, if an expression is an operand of & and it is
   not parenthesized, it must have a higher precedence than &.
   The question is how high.

2. If that expression has a higher precedence than multiplication,
   then there is no problem for instance ++x & y is clear!

3. If that expression has multiplicative precedence, or lower, then there is a
   potential problem: the programmer may be expecting a*b&c  to be a*(b&c),
   or  a<<b&c to be (a<<b)&c.  The & operator "wants to" have really high
   precedence, but doesn't.

I.e. the prec argument of prec_paren_check is the precedence level which the
operator in question (in this case bitwise end) *should* intuitively have. If
an argument has a precedence at or below this, and is unparenthesized, then
warn.