Re: Grammar with low-precedence postfix operator?

Kaz Kylheku <kaz@kylheku.com>
Wed, 11 Feb 2015 02:19:24 +0000 (UTC)

          From comp.compilers

Related articles
[2 earlier articles]
Re: Grammar with low-precedence postfix operator? anton@mips.complang.tuwien.ac.at (2015-02-07)
Re: Grammar with low-precedence postfix operator? rljacobson@gmail.com (Robert Jacobson) (2015-02-07)
Re: Grammar with low-precedence postfix operator? monnier@iro.umontreal.ca (Stefan Monnier) (2015-02-08)
Re: Grammar with low-precedence postfix operator? kaz@kylheku.com (Kaz Kylheku) (2015-02-09)
Re: Grammar with low-precedence postfix operator? DrDiettrich1@netscape.net (Hans-Peter Diettrich) (2015-02-09)
Re: Grammar with low-precedence postfix operator? jgk@panix.com (2015-02-10)
Re: Grammar with low-precedence postfix operator? kaz@kylheku.com (Kaz Kylheku) (2015-02-11)
Re: Grammar with low-precedence postfix operator? rljacobson@gmail.com (Robert Jacobson) (2015-02-21)
| List of all articles for this month |

From: Kaz Kylheku <kaz@kylheku.com>
Newsgroups: comp.compilers
Date: Wed, 11 Feb 2015 02:19:24 +0000 (UTC)
Organization: Aioe.org NNTP Server
References: 15-02-006 15-02-014 15-02-024
Keywords: parse, errors
Posted-Date: 11 Feb 2015 09:40:54 EST

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.


Post a followup to this message

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