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