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

Groups > comp.lang.c > #20612

Re: Operator precedence.

Show all headers | View raw

On 05/11/2012 01:42 PM, BartC wrote:
> "James Kuyper" <jameskuyper@verizon.net> wrote in message 
> news:4FAD3E13.7000804@verizon.net...
...
>> This is about hierarchy within the parse tree, not execution order. The
>> parse tree imposes some constraints on the execution order, but does not
>> determine it. In the expression *a + ~b * !c, *a need not be evaluated
>> until after the multiplication.
> 
> For unary operators, I think hierarchy matches execution order.

Yes, if you only consider the unary operators, it's simple. However, the
minute you throw in binary operators, the issue does comes up. C deals
with that issue by specifying a grammar that gives the postfix operators
(both unary and binary) the highest precedence and left-to-right
associativity, and gives the unary prefix operators the next-highest
precedence, with right-to-left associativity. All other operators (most
of them binary) have a lower precedence.

...
>> Which is precisely why unary ops in C occupy two different precedence
>> levels, one for postfix and one for prefix operators.
> 
> Do they? In the K&R table, they seem to occupy one level.

The relevant grammar rules are 6.5.2p1:
   postfix-expression:
            primary-expression
            postfix-expression [ expression ]
            postfix-expression ( argument-expression-listopt )
            postfix-expression . identifier
            postfix-expression -> identifier
            postfix-expression ++
            postfix-expression --
            ( type-name ) { initializer-list }
            ( type-name ) { initializer-list , }

and 6.5.3p1:
    unary-expression:
           postfix-expression
           ++ unary-expression
           -- unary-expression
           unary-operator cast-expression
           sizeof unary-expression
           sizeof ( type-name )
           _Alignof ( type-name )

The aspect of the grammar which can be described by precedence tables is
encoded in the grammar by the fact that a postfix-expression can be
parsed as a unary-expression, but a unary-expression cannot be parsed as
a postfix-expression.

>>> in your examples. The precedence table in K&R2 suggests that a series of
>>> unary ops such as op1 op2 A op3 op4 should be calculated as op1(op2((A 
>>> op4)
>>> op3)) (with 3 and 4 interchanged). They are confusing.
>>
>> That's a rather confusing statement. Why did you write "with 3 and 4
>> interchanged" rather than simply interchanging 3 and 4?
> 
> Because you might have thought it a typo otherwise. K&R says unary ops 
> associate from  right to left. So op4 first.

Sorry - I misunderstood. I thought you were choosing a bizarre way of
expressing the correct parse, which is (A op3) op4.

There are only two unary postfix operators, the other postfix operators
are all binary. According to the grammar, a++-- can only be  parsed as
(a++)--, not as (a--)++. It hardly matters, though: postfix ++ and --
both require modifiable lvalues for their left operand (6.5.3.1p2), and
neither one has a result which is an lvalue. Therefore, after correctly
parsing any consecutive pair of unary postfix operators, an
implementation must diagnose a constraint violation. As a result,
associativity is pretty much irrelevant for unary postfix operators.

The associativity of postfix operators only comes up in combination with
the binary postfix operators. It's encoded in the grammar by the fact
that every grammar production for a postfix-expression that also
contains a postfix-expression contains it only on the left side of the
production, not on the right. In other words, they associate from left
to right. For instance, a.b++ is parsed as (a.b)++, not as a.(b++),
because the right operand of the member-selection operator must be an
identifier, while the left operand of postfix ++ can be another
postfix-expression.
If the grammar had mandated the second parse, rather than the first, the
result would have been a constraint violation, but it would first have
had to be correctly parsed before it could be recognized as one.

In contrast, every grammar production for unary-expression that contains
a unary-expression, contains it on the right end of the production.
That's why the prefix unary operators can be correctly described as
associating from right to left.

...
>> So you need an additional level for that, too. In C, it's not the lowest
>> precedence, so a , b = c is parsed as a, (b = c), not (a,b)=c (which
>> would be a constraint violation).
> 
> Yes, you can think of it as an extra level, but it can just be the grammar. 

Well yes, in C, it's all grammar; precedence and associativity are
merely descriptions of important features of that grammar. The process
of deriving a precedence and associativity table for C naturally starts
with the postfix operators and ends with the comma operator. Starting it
with || and ending it with the multiplicative operators is rather
arbitrary. You could just as easily have chosen to start it at the
additive operators.

>> Because C uses grammar productions rather than precedence tables, the
>> expression a ? b = c : d is not the syntax error (a?b) = (c:d), but is
>> instead a ? (b=c) : d.
> 
> The three-way ?: is too weird to even have as operator. How would you even 
> parenthesise it so that ?: is done before the assignment? Besides, according 
> to the precedence table, ?: comes before assignment!

Yes, that's the one way in which precedence tables necessarily fail to
correctly describe the C grammar. Take out the ?: operator, and a
correctly written precedence table could be a perfectly accurate
description of one aspect of the grammar.

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

Thread

Operator precedence. somenath <somenathpal@gmail.com> - 2012-05-06 20:10 -0700
  Re: Operator precedence. somenath <somenathpal@gmail.com> - 2012-05-06 20:23 -0700
  Re: Operator precedence. James Kuyper <jameskuyper@verizon.net> - 2012-05-06 23:57 -0400
  Re: Operator precedence. Kaz Kylheku <kaz@kylheku.com> - 2012-05-07 03:59 +0000
  Re: Operator precedence. pete <pfiland@mindspring.com> - 2012-05-07 05:48 -0400
    Re: Operator precedence. James Kuyper <jameskuyper@verizon.net> - 2012-05-07 07:52 -0400
      Re: Operator precedence. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-05-07 13:18 +0100
        Re: Operator precedence. James Kuyper <jameskuyper@verizon.net> - 2012-05-07 09:08 -0400
          Re: Operator precedence. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-05-07 14:36 +0100
            Re: Operator precedence. James Kuyper <jameskuyper@verizon.net> - 2012-05-07 13:29 -0400
      Re: Operator precedence. pete <pfiland@mindspring.com> - 2012-05-07 11:24 -0400
  Re: Operator precedence. "BartC" <bc@freeuk.com> - 2012-05-07 16:35 +0100
    Re: Operator precedence. jgk@panix.com (Joe keane) - 2012-05-10 19:05 +0000
      Re: Operator precedence. "BartC" <bc@freeuk.com> - 2012-05-10 20:35 +0100
        Re: Operator precedence. James Kuyper <jameskuyper@verizon.net> - 2012-05-11 09:25 -0400
          Re: Operator precedence. "BartC" <bc@freeuk.com> - 2012-05-11 16:42 +0100
            Re: Operator precedence. James Kuyper <jameskuyper@verizon.net> - 2012-05-11 12:28 -0400
              Re: Operator precedence. "BartC" <bc@freeuk.com> - 2012-05-11 18:42 +0100
                Re: Operator precedence. James Kuyper <jameskuyper@verizon.net> - 2012-05-11 15:18 -0400
                Re: Operator precedence. "BartC" <bc@freeuk.com> - 2012-05-11 22:52 +0100
                Re: Operator precedence. James Kuyper <jameskuyper@verizon.net> - 2012-05-11 18:39 -0400
                Re: Operator precedence. Ike Naar <ike@sverige.freeshell.org> - 2012-05-11 19:20 +0000
                Re: Operator precedence. Ike Naar <ike@sverige.freeshell.org> - 2012-05-11 19:28 +0000
                Re: Operator precedence. "BartC" <bc@freeuk.com> - 2012-05-11 22:28 +0100
                Re: Operator precedence. Ike Naar <ike@sverige.freeshell.org> - 2012-05-11 21:45 +0000
              Re: Operator precedence. Keith Thompson <kst-u@mib.org> - 2012-05-12 12:11 -0700
            Re: Operator precedence. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-05-11 17:37 +0100
        Re: Operator precedence. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-05-11 16:24 +0100
          Re: Operator precedence. "BartC" <bc@freeuk.com> - 2012-05-11 20:14 +0100
            Re: Operator precedence. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-05-11 20:56 +0100
              Re: Operator precedence. "BartC" <bc@freeuk.com> - 2012-05-11 22:21 +0100
                Re: Operator precedence. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-05-12 00:05 +0100
          Re: Operator precedence. jgk@panix.com (Joe keane) - 2012-05-11 22:46 +0000
            Re: Operator precedence. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-05-12 00:17 +0100
              Re: Operator precedence. jgk@panix.com (Joe keane) - 2012-05-12 19:35 +0000
                Re: Operator precedence. "BartC" <bc@freeuk.com> - 2012-05-12 22:39 +0100
            Re: Operator precedence. Keith Thompson <kst-u@mib.org> - 2012-05-12 16:07 -0700
              Re: Operator precedence. jgk@panix.com (Joe keane) - 2012-05-13 19:08 +0000
                Re: Operator precedence. Keith Thompson <kst-u@mib.org> - 2012-05-13 13:17 -0700
                Re: Operator precedence. jgk@panix.com (Joe keane) - 2012-05-14 21:06 +0000
                Re: Operator precedence. Keith Thompson <kst-u@mib.org> - 2012-05-14 20:42 -0700
                Re: Operator precedence. Kaz Kylheku <kaz@kylheku.com> - 2012-05-13 23:20 +0000
      Re: Operator precedence. Keith Thompson <kst-u@mib.org> - 2012-05-10 15:24 -0700

csiph-web