Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.compilers > #1527
| 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> |
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
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