gwyn@brl-smoke.UUCP (04/10/87)
In article <6800@brl-adm.ARPA> dsill@NSWC-OAS.arpa writes: >Doug Gwyn wrote: >>... However, the dpANS for C has not changed >>the significance of parentheses; C compilers have always been allowed to >>reorder theoretically-commutative and -associative operations. >>... > >From K&R, page 185: >"Expressions involving a commutative and associative operator (*, +, &, |, ^) > may be rearranged arbitrarily, even in the prescence of parentheses; to force > a particular order of evaluation an explicit temporary must be used." > >This implies that when these operations aren't commutative AND associative, >as in floating point, the expressions can't be reordered. Wrong! That is why I was careful to use the qualifier "theoretically-". The abstract arithmetic definition of * and + for all numbers in C IS associative and commutative. It is not intended that machine quirks that cause deviation from the theoretical model in practice somehow cancels the model -- the programmer is not expected to have to take specific machine properties into account in order to determine whether * and + are considered associative and commutative; they are announced to be such for purposes of operation reordering by K&R (and the dpANS). > If this is the >case, what is the unary + needed for if it was added for the benefit of >"numeric" programmers? Unary plus was originally added for "symmetry" with unary minus. It was only later when the request for a way to force evaluation order in expressions was considered that it was observed that unary plus happens to have that nice effect. > Are there compilers that are reordering expressions >with (*, +, &, |, ^) even when they aren't supposed to? There is no such thing as a time when "they aren't supposed to" (if sequence points, volatile data, or other such subtleties are not involved). In fact there are many C compilers that rearrange such expressions, as they have always been permitted to do. >Given that a means for forcing the compiler to respect parentheses is needed, >couldn't something less syntactically "tacky" than the unary + have been found? >I don't think it's intuitive or obvious. Many people would agree that it's a bit kludgy, but since the facility was added anyway for other (not necessarily terrific) reasons and has the desired effect, there is no need to invent anything more for this.
jimv@omepd.UUCP (04/10/87)
In article <6800@brl-adm.ARPA> dsill@NSWC-OAS.arpa writes: >Given that a means for forcing the compiler to respect parentheses is needed, >couldn't something less syntactically "tacky" than the unary + have been found? >I don't think it's intuitive or obvious. Someone, I don't remember who, >suggested a "respect" reserved word to be used as: > respect x = expression...; >which wouldn't be too bad. I'm sorry, but "respect ..." doesn't seem like an improvement over the unary + syntax to me. (There's a Rodney Dangerfield joke in here somewhere.) An alternate approach is to write a preprocessor to run over the C code that enforces parentheses by rewriting those expressions as individual statements to guarantee the order of evaluation. I grant that some rewrites are tricky to do since expressions and statements don't always mix well in C, but this approach does enforce the order of evaluation. One gotcha might be that, to get reasonable code generated, the rewriting could require declaring extended-width floating-point data types (such as long double) which may or may not be supported in any particular compiler. I'm thinking here of those floating-point chips that prefer to keep intermediate expressions in an extended-width format. I consider the rewriting approach to be somewhat similar to the inline function preprocessor I've been using here. Source level rewriting is useful, and can be done separately from the compiler, but it is easier to directly implement the desired semantics in the compiler proper. -- Jim Valerio {verdix,intelca!mipos3}!omepd!jimv, jimv@omepd.intel.com
john@viper.UUCP (04/11/87)
In article <5739@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: > >>Given that a means for forcing the compiler to respect parentheses is needed, >>couldn't something less syntactically "tacky" than the unary + have been found? >>I don't think it's intuitive or obvious. > >Many people would agree that it's a bit kludgy, but since the facility >was added anyway for other (not necessarily terrific) reasons and has the >desired effect, there is no need to invent anything more for this. As far as I'm concerned saying the unary '+' is "a bit tacky" is like saying "an icecube has a small chance of surviving a pass thru the sun". The unary + is A BAD IDEA!! I have no objection to the objective, but the method is very much in question. I've repeatedly given detailed explanations of WHY it's a bad idea, as well as several simple options which would allow reorganization when necessary but give the programmer the final say... Isn't that what a language is suppost to do in the first place??! how about giving me one (or maybe two if you can) ideas as to why it's a better idea than simply obeying the parens that the programmer put there in the first place??? I would be very interested in hearing what the process would be for me to make an official proposal to the committee. I'm tired of taking so much time talking to people who agree with me but have little or no say in the matter. I want to make sure the unary plus never gets into the final version of the standard. It will cause more problems than it's worth and makes a major point of the language into a total kludge. Doug, what do I have to do to have some REAL input into this process? I will also welcome mail from any and all people who have an opinion (pro or con) on this matter. Don't get too carried away, but tell me if you like the unary plus or if you think something else would be a better way and if so, what that -other- way might be. I'll collect a tally and post it in a week or two. SPEAK UP AND BE COUNTED... --- John Stanley (john@viper.UUCP) Software Consultant - DynaSoft Systems UUCP: ...{amdahl,ihnp4,rutgers}!{meccts,dayton}!viper!john
john@viper.UUCP (04/13/87)
In article <5746@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >In article <814@viper.UUCP> john@viper.UUCP (John Stanley) writes: >> I would be very interested in hearing what the process would be for >>me to make an official proposal to the committee. I'm tired of taking >>so much time talking to people who agree with me but have little or no >>say in the matter. I want to make sure the unary plus never gets into >>the final version of the standard. It will cause more problems than >>it's worth and makes a major point of the language into a total kludge. > >Sigh. You're totally wrong about this. I've tried to correct the >misimpressions people seem to have about the significance of () in C, >which is simply to alter expression parsing (override default operator >associativity and precedence), and to explain that the addition of >unary + to the language has no effect unless you use it, in which case >it can be used to obtain additional functionality that people seem to >be clamoring for WHICH WAS NOT POSSIBLE BEFORE. I get the feeling that >you're not listening.. > Oh, we're listening Doug... You're the one who dosen't seem to get the point. The point is, we don't like the construct X3J11 has come up with. Parens are intuative. They fall into the wyciwyg (What you C is what you get) system of programming. What we want also falls into the category of "WAS NOT POSSIBLE BEFORE". What makes the method you've come up with somehow sacred and imutable? I KNOW X3J11 has put -a-lot- of time and effort into this and it may be that they have invested too much time and "emotional effort" to even consider an alternative which goes against their ideas even if it -might- be a better idea. I don't think that should stop me from at least trying to get the point across... Do you? >Keep in mind that all this has been discussed >before and decided on; to get it changed you will have to be quite >convincing. (If you don't understand how anyone could rationally >disagree with your "obvious" ideas, then don't bother to send in a >comment, since in that case you're not likely to accomplish anything >beyond wasting both your and the committee's time.) > (chuckle) Well put. Have no fear. If I can't make up an argument that's at least halfway convincing the committe will never waste a moment of time on the ideas I intend to present. I, for one, have no desire to "waste" anyones time, including my own... >Send your comments to the address that accompanied the public review >document that you presumably got through Global Engineering. (If you >don't have a copy, get it, because it's hard to take comments very >seriously when they aren't based on what was actually proposed.) > By all means I intend to aquire a copy. I's quite possible that all this may be a misunderstanding that will be cleared up by reading "the word of X3J11". How about providing the address and telling me how much money I need to send so I can start...? --- John Stanley (john@viper.UUCP) Software Consultant - DynaSoft Systems UUCP: ...{amdahl,ihnp4,rutgers}!{meccts,dayton}!viper!john
gwyn@brl-smoke.UUCP (04/14/87)
In article <833@viper.UUCP> john@viper.UUCP (John Stanley) writes: >Oh, we're listening Doug... You're the one who dosen't seem to get the >point. The point is, we don't like the construct X3J11 has come up with. I understand that; my point was that much of the flaming has shown misperceptions about what the C language was like even BEFORE X3J11. Most of what people are saying they don't like about "X3J11" parentheses rules has actually been part of the C language all along. And the rules aren't the way they are by accident, either, but rather because that's they way the designers of C decided they needed to be, for good reasons. I like them just they way they are, and I have done a lot of numerical programming in C (Fortran, too, for that matter). >Parens are intuative. They fall into the wyciwyg (What you C is what you >get) system of programming. Semantics for parentheses in a programming language are certainly not intuitive, or at least to the degree that they are, they're not unique! Lisp, Fortran, C, and assemblers all give different meanings to parentheses. Arguments that Fortran rules are "better" are specious. Arguments that Fortran rules are more mathematically correct are wrong. Furthermore, C is not Fortran; it has its own unique set of characteristics (such as pointers and preprocessing) that help determine the viability of proposed language features. >How about providing the address and telling me how >much money I need to send so I can start...? I don't know that the draft American National Standard X3.159-198x is definitely still available now that the public review period has closed (where were you?), but if so it can be ordered from Global Engineering Documents, Inc. by calling (800)854-7179. Single copy price was $65.00.