Re: Grammar with low-precedence postfix operator?

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.

Return to the comp.compilers page.
Search the comp.compilers archives again.