Path: utzoo!mnetor!uunet!husc6!necntc!ima!haddock!karl
From: karl@haddock.ISC.COM (Karl Heuer)
Newsgroups: comp.lang.c
Subject: Re: Power proposal for ANSI C
Message-ID: <2335@haddock.ISC.COM>
Date: 20 Jan 88 02:01:38 GMT
References: <38384@sun.uucp> <2252@haddock.ISC.COM> <3421@ihlpf.ATT.COM>
Reply-To: karl@haddock.ima.isc.com (Karl Heuer)
Organization: Interactive Systems, Boston
Lines: 69
Summary: Read the grammar again

In article <3421@ihlpf.ATT.COM> nevin1@ihlpf.UUCP (00704A-Liber,N.) writes:
>In article <2252@haddock.ISC.COM> karl@haddock.ima.isc.com (Karl Heuer) writes:
>>power-expression:
>>	postfix-expression
>>	postfix-expression *^ cast-expression
>>
>>unary-expression:
>>	power-expression
>>	++ unary-expression
>>	-- unary-expression
[	unary-operator cast-expression
]
>What about 'unary-expression ++'?  Currently, this is on the same level as
>pre-incrementing with the distinction being associativity.

That's the way it's usually described, but an equivalent formulation is that
postfix unary has a higher precedence than prefix unary (and there's no need
to talk about "associativity" of a unary operator).  This is already in the
ANSI grammar at the "postfix-expression" level.

>Would you split these two and put power between them?

Yes.  That's what I said in the grammar as well as the English text.

>Also, what would the associativity be for power?  [2 *^ 3 *^ 5]

I believe the grammar is unambiguous.  Omitting a few trivial productions,

expression("2*^3*^5")
power-expression("2*^3*^5")
postfix-expression("2") *^ cast-expression("3*^5")
                           unary-expression("3*^5")
                           power-expression("3*^5")
                           postfix-expression("3") *^ cast-expression("5")

Thus, the parsing is 2*^(3*^5).  It can't parse as (2*^3)*^5 because "2*^3"
(without parens) is not a postfix-expression.

>>I think 2 *^ -1 should be undefined (as is 1 << -1), rather than zero.
>
>Since we are defining the 'power' operator and not the 'integer power'
>operator, 2 *^ (-1) should return (double)0.5 and then be demoted
>to an integer class, if necessary.  The power operator should not return two
>different numbers ... based on the types of the arguments.  This is one of
>the major reasons I don't like the intro of the power operator into C.

Actually, we are defining several operators which share a common symbol.  Just
as the "/" symbol invokes the integer-divide operator when both operands are
integers (it most certainly does *not* invoke floating-point divide and then
truncate the result), "*^" should invoke the integer-power operator when both
operands are integers.  I thought that was the whole point!

>Your example (2 *^-1, no parentheses around -1) is undefined because of the
>way you defined your precedence; i.e., 2 *^ -1 groups as (2 *^ -) 1 (sort of).

I already thought of that problem.  It's covered by the grammar.

power-expression("2*^-1")
postfix-expression("2") *^ cast-expression("-1")
                           unary-expression("-1")
                           unary-operator("-") cast-expression("1")

>(BTW, maybe ANSI should define (1 << -1) as right-shifting by 1--any
>response to this out there?)

Bad idea.  It would require the compiler to generate extra code if the right
operand is nonconstant.

Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint