Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.compilers > #1527

Re: Grammar with low-precedence postfix operator?

From Kaz Kylheku <kaz@kylheku.com>
Newsgroups comp.compilers
Subject Re: Grammar with low-precedence postfix operator?
Date 2015-02-11 02:19 +0000
Organization Aioe.org NNTP Server
Message-ID <15-02-025@comp.compilers> (permalink)
References <15-02-006@comp.compilers> <15-02-014@comp.compilers> <15-02-024@comp.compilers>

Show all headers | View raw


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.

Back to comp.compilers | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

Grammar with low-precedence postfix operator? Robert Jacobson <rljacobson@gmail.com> - 2015-02-05 13:27 -0500
  Re: Grammar with low-precedence postfix operator? Kaz Kylheku <kaz@kylheku.com> - 2015-02-05 21:10 +0000
    Re: Grammar with low-precedence postfix operator? Robert Jacobson <rljacobson@gmail.com> - 2015-02-07 10:30 -0800
  Re: Grammar with low-precedence postfix operator? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-02-07 11:27 +0000
    Re: Grammar with low-precedence postfix operator? jgk@panix.com (Joe keane) - 2015-02-10 21:03 +0000
      Re: Grammar with low-precedence postfix operator? Kaz Kylheku <kaz@kylheku.com> - 2015-02-11 02:19 +0000
  Re: Grammar with low-precedence postfix operator? Stefan Monnier <monnier@iro.umontreal.ca> - 2015-02-08 12:34 -0500
    Re: Grammar with low-precedence postfix operator? Kaz Kylheku <kaz@kylheku.com> - 2015-02-09 01:24 +0000
      Re: Grammar with low-precedence postfix operator? Hans-Peter Diettrich <DrDiettrich1@netscape.net> - 2015-02-09 08:05 +0100
  Re: Grammar with low-precedence postfix operator? Robert Jacobson <rljacobson@gmail.com> - 2015-02-21 12:55 -0800

csiph-web