dsill@NSWC-OAS.arpa (04/08/87)
>It is not a _minor_ matter when a piece of code doesn't execute the way it >reads, and it is not a _minor_ matter when something like the proposed unary >plus override on parenthesis evaluation order is added to a language. I thought I was the only one who thought the unary plus was a kludge. But then I didn't even realize my parentheses weren't being honored. Seriously. >Please, when you make language design decisions, think of the poor boob who >has to use the resulting mess, and take the time to do it right, not just >patch the patches. I agree. Could someone please tell me under what circumstances parentheses can be "optimized" out? -Dave Sill dsill@nswc-oas.arpa
neville@ads.arpa (04/08/87)
>>It is not a _minor_ matter when a piece of code doesn't execute the way it >>reads, and it is not a _minor_ matter when something like the proposed unary >>plus override on parenthesis evaluation order is added to a language. > >I thought I was the only one who thought the unary plus was a kludge. But >then I didn't even realize my parentheses weren't being honored. Seriously. Ditto. i have thought, from the first i heard of it, that the unary '+' was a remarkably bad syntax choice and a kludge to cover basic deficiencies in handling parenthesis evaluation directives. It wasn't until reading about unary '+' that i knew that C might disregard my parens. The other bad choice, in my opinion, is '##' in the preprocessor for concatenation. What i prefer (and it was implemented in a special preprocessor done by Mary Larson at U.Mass.) is to borrow the backquote construct from the Un*x shells: let var_base_name_`count` become var_base_name_<value-of-count>. If the part within `` wasn't a compile-time variable, then you would just have simple concatenation. i also would have the backquote mechanism do substitutions WITHIN QUOTED STRINGS, i.e. it would be absolute. Of course, you could escape the backquote character if needed. In our BSD's /lib/cpp, the backquote char is used for BCD constants but that didn't interfere with our usage. If there are other features with which this would interfere, i would like to hear about them. i fully realize that some people might dislike this method because it carries another Un*x notion into the world of C, but i believe this particular Un*x notion is one of greatest things since sliced bread. -neville ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ U.S. Mail: Neville D. Newman Advanced Decision Systems 201 San Antonio Circle, Suite 286 Mountain View, CA 94040-1289 Phone: (415) 941-3912 Net mail: neville@ads.arpa (internet-relative)
jas@rtech.UUCP (04/10/87)
Sorry to add to a discussion that may have gone on too long; I'll be brief. Postings like this betray some confusion: >>>... it is not a _minor_ matter when something like the proposed unary >>>plus override on parenthesis evaluation order is added to a language. >> >>... I didn't even realize my parentheses weren't being honored. Seriously. > > It wasn't until reading about unary '+' that i knew that C might > disregard my parens. >I think parens should be followed without any micky-mousing from the compiler. PARENTHESES AFFECT PRECEDENCE, NOT EVALUATION ORDER. THESE ARE 2 DIFFERENT THINGS. To put it another way, parentheses affect the shape of the parse tree for an expression; evaluation order is an order in which the parse tree is walked. Unary '+' does not "override" parentheses, nor may a compiler "disregard my parens." Parens have a precise and essential function, entirely distinct from order of evaluation. If you want to give the programmer some control over evaluation order (a reasonable thing), some options for C are: (1) Force the programmer to explicitly use temporaries (the current solution); (2) Allow unary '+' as an order-of-evaluation directive (the ANSI C solution); (3) Come up with some other syntax for order-of-evaluation directives. People may argue over which of these options is most reasonable. What is NOT reasonable is to use parentheses as an order-of-evaluation directive. They are already taken, for altering operator precedence. Is the distinction really so difficult to understand? -- Jim Shankland ..!ihnp4!cpsc6a!\ rtech!jas ..!ucbvax!mtxinu!/
dik@mcvax.UUCP (04/12/87)
In article <752@rtech.UUCP> jas@rtech.UUCP (Jim Shankland) writes: > PARENTHESES AFFECT PRECEDENCE, NOT EVALUATION ORDER. THESE ARE 2 DIFFERENT > THINGS. To put it another way, parentheses affect the shape of the parse > tree for an expression; evaluation order is an order in which the parse > tree is walked. I may be dense, but I do not understand. If I write a + (b + c) the parenthesis are just there to affect precedence, the second + has now higher precedence than the first. Evaluation order is something different, I do not mind whether you evaluate a before b or c, or the other way round. (This silly remark has been put up a number of times. Parenthesis ought to affect precedence, but I want an effect on precedence if I write a + (b + c), just as I want it if I write a * (b + c). However, the C language should not provide it because of all those parenthesis coming up from macros. Unless of course, the ANSI C-committee decides that parenthesis from macros are different from normal parenthesis. {which of course is true, unless your macro ....}) I look, I used parenthesis and braces! -- dik t. winter, cwi, amsterdam, nederland INTERNET : dik@cwi.nl BITNET/EARN: dik@mcvax
john@viper.UUCP (04/13/87)
In article <348@zuring.mcvax.cwi.nl> dik@zuring.UUCP (Dik T. Winter) writes: > Parenthesis ought >to affect precedence, but I want an effect on precedence if I write >a + (b + c), just as I want it if I write a * (b + c). This is an excelent example... --- John Stanley (john@viper.UUCP) Software Consultant - DynaSoft Systems UUCP: ...{amdahl,ihnp4,rutgers}!{meccts,dayton}!viper!john
m5d@bobkat.UUCP (04/14/87)
In article <348@zuring.mcvax.cwi.nl> dik@zuring.UUCP (Dik T. Winter) writes: >In article <752@rtech.UUCP> jas@rtech.UUCP (Jim Shankland) writes: > > PARENTHESES AFFECT PRECEDENCE, NOT EVALUATION ORDER. THESE ARE 2 DIFFERENT > > THINGS. To put it another way, parentheses affect the shape of the parse > > tree for an expression; evaluation order is an order in which the parse > > tree is walked. >I may be dense, but I do not understand. If I write a + (b + c) the >parenthesis are just there to affect precedence, the second + has now higher >precedence than the first. >-- >dik t. winter, cwi, amsterdam, nederland I think that the best way to view the parentheses question is to re-read Mr. Shankland's assertion that the parentheses dictate the shape of the parse tree. Most (all) reorganizations of the expression happen in the parse tree (or in a reconstructed parse tree or graph). For example, given the tree + /* a + (b + c) , or a + b + c maybe */ a + b c the code generator may decide "gee, if I did this addition differently, I could save a register!" + mov a, r0 a + ==> mov b, r1 b c add c, r1 add r1, r0 + mov a, r0 + c ==> add b, r0 a b add c, r0 Of course, if the original expression were a * (b + c), no rearrangement could be made: * a + b c (unless the value of `a' were known to be a power of two or something, and the machine has some fancy "load-and-scale" instruction, in which case the compiler might distribute the multiply.) Anyway, I still say that while I appreciate the importance of controlling round-off and "dissappearing value" errors, I worry about it about as much as I worry about catching smallpox. I honestly have never been in such a situation, and I suspect that lots of people writing system software are in the same boat. -- Mike McNally, mercifully employed at Digital Lynx --- Where Plano Road the Mighty Flood of Forest Lane doth meet, And Garland fair, whose perfumed air flows soft about my feet... uucp: {texsun,killer,infotel}!pollux!bobkat!m5d (214) 238-7474
jtr485@umich.UUCP (Johnathan Tainter) (04/15/87)
In article <752@rtech.UUCP>, jas@rtech.UUCP writes: > Sorry to add to a discussion that may have gone on too long; I'll be brief. > > Postings like this betray some confusion: > > > It wasn't until reading about unary '+' that i knew that C might > > disregard my parens. > > >I think parens should be followed without any micky-mousing from the compiler. > > PARENTHESES AFFECT PRECEDENCE, NOT EVALUATION ORDER. THESE ARE 2 DIFFERENT > THINGS. To put it another way, parentheses affect the shape of the parse > tree for an expression; evaluation order is an order in which the parse > tree is walked. Unary '+' does not "override" parentheses, Correct so far. > nor may a compiler > "disregard my parens." Parens have a precise and essential function, entirely > distinct from order of evaluation. Sorry, Jim. But, you are the one showing confusion here. The compiler CAN disregard parens! (K&R page 49) Unary plus exists to keep it from doing so. Unary plus does NOT alter order of evaluation, it just maintains precedence specified by the parentheses. i.e. on a simple stack machine: +(x + y) + z CANNOT generate push x; push y; push z; add; add OR push y; push x; push z; add; add OR push x; push z; push y; add; add OR push y; push z; push x; add; add OR push x; push z; add; push y; add OR push y; push z; add; push x; add OR push z; push x; add; push y; add OR push z; push y; add; push x; add but (x + y) + z can. This says nothing about whether the former is: push x; push y; add; push z; add OR push y; push x; add; push z; add OR push z; push x; push y; add; add OR push z; push y; push x; add; add --j.a.tainter > Jim Shankland
stuart@bms-at.UUCP (Stuart D. Gathman) (04/16/87)
If y'all succeed in turning C into Fortran, I'll just have to get GNU C before it gets corrupted. If the possibility that the compiler might reorder your expressions bothers you, *don't program in 'C'*. Try Fortran, Algol, SPL, whatever. 'C' was not designed for applications programmers. It can be best described as a portable, structured assembler. The proposal to make parens work like Fortran defeats the purpose of 'C'. If 'C' is destroyed in this manner, I might revert to Pascal. The current rage of writing every piece of code in the world in 'C' may be doing the language a disservice. I am glad there are some LISP programmers out there who realize the value of using the right tool for the job. If you like structures, pointers, and user defineable types, but don't like the close attention to portability required, try Pascal. It has a lot of improvements over 'C' along those lines a) no need to worry about how many bits integral types might have. Just define the range! Pascal will automatically generate bitfields, bytes, words, regardless of architecture. You can even select between optimizing space (PACKED) or speed (not PACKED). b) enumeration constants are actually type checked. c) You don't have to remember the '&' before function arguments passed as pointers. Just declare them as VAR and compiler takes care of the rest. d) Parens define order of evaluation as well as syntax. This is just a partial list. There is a price to pay, but there are just different tradeoffs than with 'C'. There are some dumb things about 'C' (like making vars public instead of private by default), but the definition of parens is not one of them. The ambiguous definition of 'int' and certain operators is also based on careful consideration. If you want a variable with a particular number of bits, DON'T USE 'int'. That is not the purpose of 'int'. If you want parens to determine order of evaluation, DON'T USE 'C'. That is not the purpose of 'C'. -- Stuart D. Gathman <..!seismo!dgis!bms-at!stuart>