Path: utzoo!utgpu!water!watmath!clyde!ima!haddock!karl
From: karl@haddock.ISC.COM (Karl Heuer)
Newsgroups: comp.lang.c
Subject: Re: Power proposal for ANSI C
Message-ID: <2369@haddock.ISC.COM>
Date: 23 Jan 88 01:31:48 GMT
References: <38384@sun.uucp> <2252@haddock.ISC.COM> <3421@ihlpf.ATT.COM> <2335@haddock.ISC.COM> <3474@ihlpf.ATT.COM>
Reply-To: karl@haddock.ima.isc.com (Karl Heuer)
Organization: Interactive Systems, Boston
Lines: 109

In article <3474@ihlpf.ATT.COM> nevin1@ihlpf.UUCP (00704A-Liber,N.) writes:
>>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).
>
>Not entirely true.  Expressions such as *--pointer still require knowledge of
>associativity to be correctly evaluated.

No, it's completely unambiguous.  You seem to be thinking that, unless some
type of "associativity" is defined, it will parse as (* --) pointer.  That
doesn't make sense, because "*" expects an expression (not another operator)
as its operand.  Even if "*" had a higher precedence than "--", it would
still parse correctly.

Or to put it another way, that's not what *I* mean by associativity.

>Assuming this is your order (from highest to lowest):
>1.	(); []; .; ->	(left to right)
>2.	postfix unary	(right to left)
>3.	power		(right to left)
>4.	prefix unary	(right to left)
>5.	*; /; %		(left to right)
>6 and below.	the same as K&R

Yes, except that classes 1 and 2 can be combined, as in the ANSI grammar.

>Then --a power --b cannot be done. It would be grouped as
>(-- ((a power --) b), which is illegal.

It would not be grouped that way, because (a *^ --) is not a valid parsing.

>>I already thought of that problem [2 *^ -1].  It's covered by the grammar.
>>
>>power-expression("2*^-1")
>>postfix-expression("2") *^ cast-expression("-1")
>>                           unary-expression("-1")
>>                           unary-operator("-") cast-expression("1")
>>
>Then you are not clearly defining the precedence, in English.  Please describe
>precisely how you want evaluation to go.

I included the grammar fragment as the precise definition.  You want English?
"*^ has a lower precedence than postfix unary, but higher than prefix unary."
I don't think I can make it any clearer.

>If power were to be added (PLEASE DON'T), I believe it should have a
>precedence [just below unary] and associate left to right; it would match
>closer to the mathematical definition this way.

Think again -- the mathematical definition is right to left.

>Also, notice that all the right to left operators are either assignment or
>unary;

And the ternary operator.

>having an augmented assignment operator for an operator which groups right to
>left seems inconsistent

(You've lost me.  It's inconsistent for both *^ and *^= to be R-to-L?)  I
don't see any problem with this.  I figure that the reason "/" is L-to-R is
because that makes better mathematical sense; for the same reason, "*^" should
be R-to-L.

>Also , by your method
>(++a pow b) == ++(a pow b)
>and
>(a pow b++) == (a pow (b++))
>are how groupings would be done.  This does not look intuitive at all.

I agree.  But if "++" and "-" are to have the same precedence, one can't have
"++a *^ 2" and "- a*^2" both do the right thing.  After rethinking this, I've
decided that it's not so important for "- a*^2" to work (and it could be
caught by lint, anyway).  So the best precedence would probably be just below
unary, as you said.  The revised grammar would be:

power-expression:
	cast-expression
	cast-expression *^ power-expression

multiplicative-expression:
	power-expression
	multiplicative-expression * power-expression
	multiplicative-expression / power-expression
	multiplicative-expression % power-expression

>>>>I think 2 *^ -1 should be undefined (as is 1 << -1), rather than zero.
>
>... I would rather have (2 pow (-1)) evaluate to 0, (1 pow (-1)) evaluate to
>1 than to just be 'undefined'; i.e., crash my program!

The question is, would anybody ever use int-expr *^ negative-int-expr and
depend on the result being zero?  I'd think that such a situation is probably
a program error anyway, in which case it doesn't matter what happens.

>>>(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.
>
>What does it do now if the the right operand is negative and inside a variable
>or an expression?

Officially, it's "undefined".  In practice, you get whatever the architecture
gives you.  On some, it really is a right shift; on others, you get zero.
There may even be some where it causes a trap.

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