[comp.lang.c] min and max, power, etc: no defined precedence

gnu@hoptoad.uucp (John Gilmore) (01/25/88)

> > >What's the appropriate precedence for these operators?

Bog forbid that any new operators get added in the last-minute rush
to a standard -- they'll probably end up like the bills that get passed
by Congress on the last 3 days of the session.  Trash, badly thought
through, passed because somebody owed somebody else a favor.

But if any operators *DO* slip through, I recommend that they have *NO
DEFINED PRECEDENCE*.  That's right, we don't need to make C's 11-level
precedence into a 12-level precedence.  Force the user to fully
parenthesize any new operator, else the compiler rejects the expression.

(I was an early convert to APL -- in which all functions have the same
precedence.  It was easy to read once you got the hang of it -- sort
of like "infix polish notation".  I still have to dig out reference
manuals to figure what C should do -- when it isn't obvious, I just
parenthesize instead.  For new operators it is by definition not obvious.)
-- 
{pyramid,ptsfa,amdahl,sun,ihnp4}!hoptoad!gnu			  gnu@toad.com
		"Watch me change my world..." -- Liquid Theatre

ok@quintus.UUCP (Richard A. O'Keefe) (01/27/88)

In article <1411@mips.mips.COM>, hansen@mips.COM (Craig Hansen) writes:
> In article <3930@hoptoad.uucp>, gnu@hoptoad.uucp (John Gilmore) writes:
> > > > >What's the appropriate precedence for these operators?
> > But if any operators *DO* slip through, I recommend that they have *NO
> > DEFINED PRECEDENCE*.  That's right, we don't need to make C's 11-level
> > precedence into a 12-level precedence.  Force the user to fully
> > parenthesize any new operator, else the compiler rejects the expression.
> 
> I have designed a language/compiler that has this precise feature for
> ALL operators, and would just like to add that it's WONDERFUL.  It not

It's been half-done:  Wirth tried to "simplify" Pascal by flattening
the operator precedence.  Dunno about you, but the result strikes me
as a major pain.
It's been done before:  APL has been doing this for years.
Remember APL: the language people keep screaming "unreadable" at?
It's been done before:  anyone remember PL/11?  Anyone *like* PL/11?
It's been done even better:  Lisp has no operators...

The problem in C is not so much the number of precedence levels,
as that many operators cannot be distinguished by operand type.
For example, letting x be any scalar variable, and y be any
non-register variable, x&&&y is legal...

nevin1@ihlpf.ATT.COM (00704a-Liber) (01/28/88)

In article <3930@hoptoad.uucp> gnu@hoptoad.uucp (John Gilmore) writes:
>
>But if any operators *DO* slip through, I recommend that they have *NO
>DEFINED PRECEDENCE*.  That's right, we don't need to make C's 11-level
>precedence into a 12-level precedence.  Force the user to fully
>parenthesize any new operator, else the compiler rejects the expression.

In other words, you want to make this inconsistent with everything else in C.
This would be OK if nothing else had precedence, but not as things stand now.
I find expressions with lots of parentheses very hard to read.  I really don't
want expressions such as 'x = y min z' to be undefined.

Another thing:  if the honoring of parens goes through, this might lead to some
very unoptimized code when min and max are used.

I agree with you that no more operators should be added to C.  But, if some are
added, then they should be assigned a precedence and associativity like
everything else.
-- 
 _ __			NEVIN J. LIBER	..!ihnp4!ihlpf!nevin1	(312) 510-6194
' )  )				"The secret compartment of my ring I fill
 /  / _ , __o  ____		 with an Underdog super-energy pill."
/  (_</_\/ <__/ / <_	These are solely MY opinions, not AT&T's, blah blah blah

nevin1@ihlpf.ATT.COM (00704a-Liber) (01/28/88)

In article <1411@mips.mips.COM> hansen@mips.COM (Craig Hansen) writes:
>In article <3930@hoptoad.uucp>, gnu@hoptoad.uucp (John Gilmore) writes:
>> But if any operators *DO* slip through, I recommend that they have *NO
>> DEFINED PRECEDENCE*.  That's right, we don't need to make C's 11-level
>> precedence into a 12-level precedence.  Force the user to fully
>> parenthesize any new operator, else the compiler rejects the expression.
>
>I have designed a language/compiler that has this precise feature for
>ALL operators, and would just like to add that it's WONDERFUL.  It not

I wonder ... have you just designed an infix version of Lisp (which can be done
with Lisp itself, but you have to be clever about it)? :-)

>Actually, a _little_ precedence snuck in. Unary operators have
>precedence over binary operators, but that rule turns out to be very
>intuitive and easy to remember.

So is the rule that multiplication comes above addition, or that the arithmetic
operators come above the logical connectives, etc.

These suggestions are fine for other languages, but not for C.  This would
change the language too much for it to be called C.
-- 
 _ __			NEVIN J. LIBER	..!ihnp4!ihlpf!nevin1	(312) 510-6194
' )  )				"The secret compartment of my ring I fill
 /  / _ , __o  ____		 with an Underdog super-energy pill."
/  (_</_\/ <__/ / <_	These are solely MY opinions, not AT&T's, blah blah blah