Wed, 11 Feb 2015 02:19:24 +0000 (UTC)

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

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.