esg@mtx5a.UUCP (ed gokhman) (03/04/86)
Hi: The ANSI draft makes case for the unary + operator with the following example: An expression a + (b + c) may be calculated by some implementations as (a + b) + c. To enforce the intended precedence of operations one should use a + +(b + c). Question: what is the rational for not saying that an implementation *must* respect parenthesising as intended rather then providing an extra operator simply to state "i mean these parenthesis" ? Thanx in advance, Ed Gokhman
barmar@mit-eddie.MIT.EDU (Barry Margolin) (03/09/86)
In article <1227@mtx5a.UUCP> esg@mtx5a.UUCP (ed gokhman) writes: >An expression a + (b + c) may be calculated by some >implementations as (a + b) + c. To enforce the >intended precedence of operations one should use >a + +(b + c). > >Question: what is the rational for not saying that an > implementation *must* respect parenthesising > as intended rather then providing an extra > operator simply to state "i mean these parenthesis" ? I don't know what the committee's explanation is, but I agree with them for the following reason: Parentheses in expressions already have a meaning, that of overriding the default precedence. In the expression f(a)*(b+c), the parentheses mean that the result of the function call should be multiplied by the sum. When writing that, the programmer ordinarily doesn't care which is computed first, the function call or the sum. Making parentheses have two meanings would restrict the transformations that optimizers may perform. To me, this is what it means for an implementation to "respect parenthesising as intended." -- Barry Margolin ARPA: barmar@MIT-Multics UUCP: ..!genrad!mit-eddie!barmar
brooks@lll-crg.ARpA (Eugene D. Brooks III) (03/09/86)
In article <1227@mtx5a.UUCP> esg@mtx5a.UUCP (ed gokhman) writes: >The ANSI draft makes case for the unary + operator ... > >Question: what is the rational for not saying that an > implementation *must* respect parenthesising > as intended rather then providing an extra > operator simply to state "i mean these parenthesis" ? It was probably done so as not to break old code :-)
franka@mmintl.UUCP (Frank Adams) (03/11/86)
[Not food] I have a suggestion for the C standardization committee. Rather than using a unary + operator to force the order of evaluation, why not use a different kind of parentheses; specifically, square brackets? I think something like: a + [b + c] is easier to read than a + +(b + c) I see no more problem with confusing this use of square brackets with indexing than there is now confusing parentheses for grouping with function calls. Frank Adams ihnp4!philabs!pwa-b!mmintl!franka Multimate International 52 Oakland Ave North E. Hartford, CT 06108
msb@lsuc.UUCP (Mark Brader) (03/11/86)
People who don't think (a+b)+c, a+(b+c), and a+b+c should be
interchangeable with respect to optimization -- as they are and
will continue to be -- should consider this toy example:
#define C_TO_F(temp) ((temp)*1.8 + 32)
#define JUST_ABOVE(temp) ((temp) + epsilon) /* extern epsilon */
#define ROUND(real) ((long) .5 + (real))
scanf ("%d", &melt_pt);
desired_f_temp = ROUND (JUST_ABOVE (C_TO_F (melt_pt)));
There are, of course, NO unnecessary parentheses in the example*.
After macros are eliminated, the last line ends up as:
desired_f_temp = ((long) .5 + ((((melt_pt)*1.8 + 32)) + epsilon));
The expression uses 3 macros because that most clearly expresses
what is going on. (Well, maybe not in this toy case, but there are
lots of real-life examples.) And the parentheses are there just
because they're needed to make the macros work properly in general*.
They SHOULD NOT have anything to do with the order in which the
3 additions actually occur.
Mark Brader
*For the benefit of any novices to whom this seems strange: Consider
the first one, C_TO_F. If we omitted the inner parentheses, then
C_TO_F(a+b) would expand to (a + b*1.8 + 32), and only b would be
multiplied by 1.8. If we omitted the outer ones, then C_TO_F(c)*k
would expand to (c)*1.8 + 32*k, and only 32 would be multiplied by k.
Admittedly temperatures are neither commonly added nor multiplied,
but it is still very bad practice to omit parentheses from macros
where they might be needed for such reasons. End of lecture.bright@dataioDataio.UUCP (Walter Bright) (03/11/86)
In article <1227@mtx5a.UUCP> esg@mtx5a.UUCP (ed gokhman) writes: >An expression a + (b + c) may be calculated by some >implementations as (a + b) + c. To enforce the >intended precedence of operations one should use >a + +(b + c). > >Question: what is the rational for not saying that an > implementation *must* respect parenthesising > as intended rather then providing an extra > operator simply to state "i mean these parenthesis" ? One Answer: Compilers frequently parse the expressions into an internal form which is a binary tree. a+(b+c) would look like: + / \ a + / \ b c Where are the parentheses? They're gone, they are only used in guiding the parser as it builds the tree. Thus, the optimizer doesn't know where the parentheses were. Of course, this info could be kludged onto the tree, but if the unary + operator is used: + / \ a U+ | + / \ b c Note that the U+ operator breaks up the n-ary tree of binary + operators, thus it is easy for the optimizer to not rearrange across U+ operators. Adding another operator is an easy retrofit to most compilers, far easier than kludging in parenthesis information. Languages that do not allow an optimizer to rearrange trees within certain limits cause slow code to be generated. I take advantage of the compilers I use by knowing what rearrangements they do, so that I can write code that is more aesthetically pleasing, knowing that the optimizer will rearrange it into a faster sequence. For example, a+5+6 is turned into the tree (a+5)+6. If the compiler couldn't rearrange trees, it couldn't produce the 'optimized' a+11 tree.
jdz@wucec2.UUCP (03/12/86)
In article <1227@mtx5a.UUCP> esg@mtx5a.UUCP (ed gokhman) writes: >Question: what is the rational for not saying that an > implementation *must* respect parenthesising > as intended rather then providing an extra > operator simply to state "i mean these parenthesis" ? Optimization, plain and simple. The example you gave was: a + (b+c) might be computed as (a+b) + c. Suppose the compiler knew a and b were already in registers, and was generating code for a load/store machine (i.e. RISC-type architectures, with memory access only via load register or store register). Cheap: a_reg = a_reg + b_reg ! Sum a and b, saving where a was load c into b_reg ! Get c into register a_reg = a_reg + b_reg ! Finishing sum Expensive: store a_reg into temp ! Free up a register load c into a_reg ! Get c a_reg = a_reg + b_reg ! Compute b+c load temp into b_reg ! Get a back in a_reg = a_reg + b_reg ! Finish sum Getting a little less contrived, if any of the terms in the sum were a function call, the compiler might decide to call the function any time it wanted to during evaluation of the expression, for optimization. I.e. x = ((a + f(a+b)) + b) would be most cheaply evaluated by computing a+b, then calling f() on that term and adding the returned value to a+b. Any other way involves computing a+b twice (in one way or another). I like the notion of being able to control reordering of expressions because it lets the programmer clearly specify the order in which side-effects occur. Yeah, I know, side effects make for ugly programs, but most of us are guilty of using them more often than we should. Nobody is perfect, and we all do strange things under the pressure of deadlines. -- Jason D. Zions ...!{seismo,cbosgd,ihnp4}!wucs!wucec2!jdz Box 1045 Washington University St. Louis MO 63130 USA (314) 889-6160 Nope, I didn't say nothing. Just random noise.
kwh@bentley.UUCP (KW Heuer) (03/12/86)
In article <1147@lsuc.UUCP> lsuc!msb (Mark Brader) writes: ... > #define ROUND(real) ((long) .5 + (real)) ... >There are, of course, NO unnecessary parentheses in the example. True, they are necessary, but they are not sufficient. If you want ROUND to do what its name implies (for nonnegative arguments), you should have written it #define ROUND(real) ((long)(.5 + (real))) since unary operators (including cast) have precedence over addition. Just thought I should point that out, since you were otherwise being quite careful with parens.
greg@utcsri.UUCP (Gregory Smith) (03/13/86)
In article <1147@lsuc.UUCP> msb@lsuc.UUCP (Mark Brader) writes: > >People who don't think (a+b)+c, a+(b+c), and a+b+c should be >interchangeable with respect to optimization -- as they are and >will continue to be -- should consider this toy example: > > #define C_TO_F(temp) ((temp)*1.8 + 32) > #define JUST_ABOVE(temp) ((temp) + epsilon) /* extern epsilon */ > #define ROUND(real) ((long) .5 + (real)) > > scanf ("%d", &melt_pt); > desired_f_temp = ROUND (JUST_ABOVE (C_TO_F (melt_pt))); > >There are, of course, NO unnecessary parentheses in the example*. [example deleted, illustrating why C should be allowed to ignore ()'s in evaluating expressions] -But- ROUND(real) should be ((long)(.5+(real))). Casts are more bindish than +. So the example carries evan more weight. -- "So this is it. We're going to die." - Arthur Dent ---------------------------------------------------------------------- Greg Smith University of Toronto ..!decvax!utzoo!utcsri!greg
steven@boring.uucp (Steven Pemberton) (03/14/86)
In article <1227@mtx5a.UUCP> esg@mtx5a.UUCP writes: > The ANSI draft makes case for the unary + operator with > the following example: > > An expression a + (b + c) may be calculated by some > implementations as (a + b) + c. To enforce the > intended precedence of operations one should use > a + +(b + c). > > Question: what is the rational for not saying that an > implementation *must* respect parenthesising > as intended rather then providing an extra > operator simply to state "i mean these parenthesis" ? I find this aspect of the draft disturbing. If you don't care about the order of evaluation you can write a+b+c. But if you do care, for instance because of potential overflow or rounding problems, then you should be able to specify it using parentheses. You shouldn't need to have to use an extra unary minus: firstly you can easily overlook that sort of thing, secondly the bug will probably show up only when it's too late. I'm very much against optimisers that think they know better than you; I'm even more against standards that condone it. Steven Pemberton, CWI, Amsterdam; steven@mcvax.uucp
kwh@bentley.UUCP (KW Heuer) (03/14/86)
In article <1195@mmintl.UUCP> mmintl!franka (Frank Adams) writes: >I have a suggestion for the C standardization committee. Rather than using >a unary + operator to force the order of evaluation, why not use a different >kind of parentheses; specifically, square brackets? [ example deleted ] Well, if you make any sort of syntax error on a line containing brackets, you're likely to get a confusing message from the compiler. I'm not sure I like either notation, but +() seems simpler to me. Here's a more fundamental question. Under what circumstances would you use this feature anyway? If my understanding is correct, it only forces the compiler to respect the parentheses; it does not force the enclosed expression to be evaluated before anything else, so y[i] = x[i++]; or case '-': push(pop() - pop()); (where pop() has a side-effect) are unpredictable even with +().
lars@myab.UUCP (lars) (03/16/86)
In article <1227@mtx5a.UUCP> esg@mtx5a.UUCP writes: >An expression a + (b + c) may be calculated by some >implementations as (a + b) + c. To enforce the >intended precedence of operations one should use >a + +(b + c). Why not use this this construction: a + (volatile)(b + c) ? Would this imply that the access of 'b' and 'c' is "volatile" ? In that case the following should also work: (volatile)(a + (b + c)). -- ______________________________________________________ Lars Pensjo {decvax,philabs}!mcvax!enea!chalmers!myab!lars
henry@utzoo.UUCP (Henry Spencer) (03/17/86)
> ...if you do care [about order of evaluation] then you should be able > to specify it using parentheses... How do you tell order-of-evaluation-forcing parentheses from parentheses that are there just to get the precedence right? There is no practical way to write "a*(c+d)" without parentheses (or other annoying kludges). Yet optimizing this to "a*c + a*d" might well be useful in various situations. Parentheses already have a role: overriding default operator binding rules. Asking them to do two things at once would get messy. > ...I'm very much against optimisers that think they know better than you... Sometimes they *do* know better than you; that is exactly the point. They certainly know more than you about how to effectively exploit the underlying machine. They may well know more than you about the exact nature of the computation, e.g. if some parts of it are hidden inside macros for the sake of easy change and portability. And they don't have to worry about the other constraints, like readability and making sure that a messy formula really is right, that may limit what you write. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry
emjej@uokvax.UUCP (03/18/86)
/* Written 12:11 pm Mar 11, 1986 by bright@dataioDataio.UUCP in net.lang.c */ One Answer [to the question why not require C compilers to honor parentheses if the human takes the time to put the #$!#! things in]: Compilers frequently parse the expressions into an internal form which is a binary tree. a+(b+c) would look like: + / \ a + / \ b c Where are the parentheses? They're gone, they are only used in guiding the parser as it builds the tree. Thus, the optimizer doesn't know where the parentheses were. /* End of text from net.lang.c */ Eh? It doesn't *need* to know where the parentheses were; the order of operations is completely specified by the tree. If the coder had written a+b+c most parsers would turn it into (+ (+ a b) c), linearizing the notation to save space. Optimizers that reorder operations, especially on floating-point computation, at best will induce some detectable error, such as overflow. At worst, they will cause loss of precision. I doubt that conscientious numerical analysts would ever use a language that permitted such finagling behind the programmer's back. James Jones
jdz@wucec2.UUCP (03/22/86)
In article <138@myab.UUCP> lars@myab.UUCP (lars) writes: >In article <1227@mtx5a.UUCP> esg@mtx5a.UUCP writes: >>An expression a + (b + c) may be calculated by some >>implementations as (a + b) + c. To enforce the >>intended precedence of operations one should use >>a + +(b + c). >Why not use this this construction: >a + (volatile)(b + c) ? >Would this imply that the access of 'b' and 'c' is "volatile" ? Yes, it would; so a compiler which knew the value of B was stil hanging around in some register would be required to go back to main memory and load it in again. Same for A. That is the meaning of volatile; remembered/saved copies of the variable are not to be used. >In that case the following should also work: >(volatile)(a + (b + c)). Same problem. volatile is not the answer; it already does something else. This is the same problem I have withthe suggestion that parentheses should indicate desired order of evaluation. As has already been pointed out, the poor parenthesis already does duty to change precedence of operations. Using square brackets would just serve to confuse people (oh, how neat! says the beginning C programmer - I can use parens and brackets in my expressions interchangeably! Well...) Unary plus makes sense to me - it hangs around in the parse tree, which is one of the things optimizers optimize. They don't see the source text; they either look at the parse tree, intermediate text (probably without parens and in prefix or postfix form), or the assembler output. No parens to look at. As has been mentioned already, the unary + operator acts a a signal to any optimizer to not migrate things from below the node to above it and visa-versa. [oh, yes - if there are optimizers that operate on the input source, don't flame me for the above assumption. I'd love to hear more about them,though.] -- Jason D. Zions ...!{seismo,cbosgd,ihnp4}!wucs!wucec2!jdz Box 1045 Washington University St. Louis MO 63130 USA (314) 889-6160 Nope, I didn't say nothing. Just random noise.
gwyn@BRL.ARPA (VLD/VMB) (03/24/86)
Foo! If you want to arrange a particular order of evaluation in C, the language provides a means of specifying it. The only "problem" is Fortran programmers thinking that C should follow the Fortran model for expressions.
brooks@lll-crg.ARpA (Eugene D. Brooks III) (03/26/86)
In article <1502@wucec2.UUCP> jdz@wucec2.UUCP (Jason D. Zions) writes: >This is the same problem I have withthe suggestion that parentheses should >indicate desired order of evaluation. As has already been pointed out, the >poor parenthesis already does duty to change precedence of operations. Using Lets see now: a * (b + c) (a) means add b and c and then multiply by a but in a + (b + c) (b) the parens have no meaning because we need to reserve them for precedence changing. Is this not how you interpret the parens under these conditions? The two plus operators have equal precedence and when the parens occur it raises the precendence of the enclosed plus operator above the other. Your fault with interpreting the parens correctly in case (b) becomes its proof! >Unary plus makes sense to me - it hangs around in the parse tree, which is >one of the things optimizers optimize. They don't see the source text; they >either look at the parse tree, intermediate text (probably without parens and There is no reason why the parser can't suitably decorate the parse tree when parens are encountered as in case (b). One could even call the internal operator UPLUS to keep the compiler standards committee happy.
steve@anasazi.UUCP (Steve Villee) (03/28/86)
> How do you tell order-of-evaluation-forcing parentheses from parentheses > that are there just to get the precedence right? There is no practical > way to write "a*(c+d)" without parentheses (or other annoying kludges). > Yet optimizing this to "a*c + a*d" might well be useful in various > situations. Parentheses already have a role: overriding default operator > binding rules. Asking them to do two things at once would get messy. > Henry Spencer @ U of Toronto Zoology > {allegra,ihnp4,linus,decvax}!utzoo!henry I think there is a fundamental confusion here. If I remember correctly, the original objection was that some compilers would evaluate (a+(b+c)) as if it were ((a+b)+c). The issue is not "order of evaluation". The programmer has instructed the compiler to evaluate the expressions "a" and "b+c" in some order, and then add the two to get the result. Instead, the compiler has gone and done something different. This is justified (as is any optimization) if and only if the compiler can guarrantee that the result in either case is identical. Of course, with pure mathematical objects, the results would be identical. But with funny beasts like floating point numbers, the results are in general not identical, and thus the compiler is wrong if it switches expressions on me. I emphasize again, parentheses are not being used to specify an order of evaluation. The expression (a+b+c) has two interpretations which in general are quite different, and parentheses are simply being used to specify one or the other. Once an unambiguous expression like (a+(b+c)) has been specified, the order in which the pieces of this expression are evaluated are (by the language definition) up to the compiler. If the order of evaluation makes a difference (which it might if "a" were a function call, for instance), and if the programmer depends on some particular order of evaluation, then the programmer is wrong in that case. In your example above, the expressions "a*(c+d)" and "a*c + a*d" are, in general, different expressions. I don't want the compiler making this switch either, unless it can guarrantee that the results are identical. Loosely speaking, I would say it is okay for integers but not for floating point numbers. --- Steve Villee (ihnp4!terak!anasazi!steve) International Anasazi, Inc. 7500 North Dreamy Draw Drive, Suite 120 Phoenix, Arizona 85020 (602) 870-3330
HARGED%ti-eg.csnet@CSNET-RELAY.ARPA (04/03/86)
> As has been mentioned already, the unary + operator acts a a signal to any > optimizer to not migrate things from below the node to above it and > visa-versa. Why do you want to embed a compiler directive in the middle of an expression? Particularly when it looks like it has some arithmetic meaning (even though it doesn't). Folks, no two ways about it: "a + +(b + c)" looks very strange (it looks like a typographical error), particularly when it is *required* to accomplish what most people intuitively assume "a + (b + c)" will accomplish. From a human factors standpoint, this proposal is a disaster. If adopted, it will become a textbook example of an anti-intuitive language construct. While it is important that compilers generate maximally optimized machine code, it is more important that humans be able to read and understand the source code. This one has the potential to introduce some truly subtle bugs ("Oh ! There's supposed to be a space between the two plus-signs !"), as well as sow confusion among user's who are not intimately familiar with code generation. Richard Hargrove Texas Instruments harged%ti-eg@csnet-relay
kwh@bentley.UUCP (KW Heuer) (04/05/86)
In article <2323@brl-smoke.ARPA> HARGED%ti-eg.csnet@CSNET-RELAY.ARPA writes: >Folks, no two ways about it: "a + +(b + c)" looks very strange (it looks >like a typographical error), particularly when it is *required* to >accomplish what most people intuitively assume "a + (b + c)" will >accomplish. From a human factors standpoint, this proposal is a >disaster. If adopted, it will become a textbook example of an >anti-intuitive language construct. While it is important that compilers >generate maximally optimized machine code, it is more important that >humans be able to read and understand the source code. This one has the >potential to introduce some truly subtle bugs ("Oh! There's supposed to >be a space between the two plus-signs!"), as well as sow confusion among >user's who are not intimately familiar with code generation. (OOE = Order-Of-Evaluation.) [0] "+()" is a bad notation, no doubt about it. If unary plus is to have any meaning at all, it should be the obvious arithmetical no-op on real numerical arguments. [1] "()" is worse. The code generator should NOT have to assume all parens specify OOE. In the example given it looks intuitive (since I could write "a+b+c" for dont-care, obviously "(a+b)+c" or "a+(b+c)" reflect intended OOE), but it's not true in general. Also, it's already been observed that expanded macros often have extraneous parens. [2] The way to specifically disambiguate in the current standard is to use an explicit temporary: "temp=b+c; a+temp". I presume the reason for the proposed unary plus operator is to remove the need for a declaration, and to reduce the compiler's work. (It's not easy for the compiler to know that "temp=b+c; a+temp" can be reduced to "a+ +(b+c)", especially if the same variable "temp" is used elsewhere for the same trick.) [3] Someone proposed using "a+(volatile)(b+c)". I think this is workable, though not quite the same meaning as volatile applied to a simple variable. [4] Finally, the most important point. WHO THE HELL IS GOING TO USE SUCH A FEATURE ANYWAY? I have *never*, to my recollection, tried to force OOE, nor seen any program that did (excluding the use of temporaries to control the order of side effects, which is not addressed by the unary plus issue). Given its extreme rarity, I think the "subtle bugs" and "confusion among [unfamiliar] users" are irrelevant -- except that someone may make a typo and accidentally invoke a unary plus. The alleged reason for "=" being assignment rather than compare is that assignment is used more often and deserves the shorter symbol. (I might believe this argument if they'd also applied it to "&&".) In my opinion, the OOE operation does not deserve a one-character symbol, nor a new keyword. I vote for [3], given the prior existence of an appropriate keyword. Karl W. Z. Heuer (ihnp4!bentley!kwh), The Walking Lint
rbj@icst-cmr (Root Boy Jim) (04/07/86)
~ (OOE = Order-Of-Evaluation.) ~ ~ [0] "+()" is a bad notation, no doubt about it. If unary plus is to have ~ any meaning at all, it should be the obvious arithmetical no-op on real ~ numerical arguments. Which is probably why they even *considered* adding it. It is non-intuitive for unary plus to be disallowed. ~ [1] "()" is worse. The code generator should NOT have to assume all ~ parens specify OOE. In the example given it looks intuitive (since I could ~ write "a+b+c" for dont-care, obviously "(a+b)+c" or "a+(b+c)" reflect ~ intended OOE), but it's not true in general. Also, it's already been ~ observed that expanded macros often have extraneous parens. Which serve to specify OOE. I think it slightly weird that K&R allowed rearranging OOE for associative operators, but mostly it doesn't hurt. Anyone for a reverse polish notation C spec? ~ [2] The way to specifically disambiguate in the current standard is to use ~ an explicit temporary: "temp=b+c; a+temp". I presume the reason for the ~ proposed unary plus operator is to remove the need for a declaration, and ~ to reduce the compiler's work. (It's not easy for the compiler to know ~ that "temp=b+c; a+temp" can be reduced to "a+ +(b+c)", especially if the ~ same variable "temp" is used elsewhere for the same trick.) The spirit of C is (was) minimalism. If you don't need it, don't put it in the language. Unary plus probably only made it in because someone discovered that it could do double duty; that of eliminating those irritating temporarys. ~ [3] Someone proposed using "a+(volatile)(b+c)". I think this is workable, ~ though not quite the same meaning as volatile applied to a simple variable. Workable maybe, but ugly by my standards. Volatile should be a keyword no one has to use except when writing device drivers. ~ [4] Finally, the most important point. WHO THE HELL IS GOING TO USE SUCH ~ A FEATURE ANYWAY? I have *never*, to my recollection, tried to force OOE, ~ nor seen any program that did (excluding the use of temporaries to control ~ the order of side effects, which is not addressed by the unary plus issue). ~ Given its extreme rarity, I think the "subtle bugs" and "confusion among ~ [unfamiliar] users" are irrelevant -- except that someone may make a typo ~ and accidentally invoke a unary plus. If you are going to live up to your nickname, you had better do some research before posting. We all know about `MAXINT', right? Well postulate `MAXFLT' & `MINFLT', which are BMF & SLF floating point numbers. We all know that `(MAXFLT + MINFLT - MAXFLT)' is `MINFLT' right? Wrong! It's zero on most machines because the sum of the first two terms generates too many bits of significance. MINFLT is just a drop in the bucket. ~ The alleged reason for "=" being assignment rather than compare is that ~ assignment is used more often and deserves the shorter symbol. (I might ~ believe this argument if they'd also applied it to "&&".) In my opinion, ~ the OOE operation does not deserve a one-character symbol, nor a new ~ keyword. It is debatable whether `&' or `&&' is used more commonly. The Bitwise And (&) is certainly a more familiar construct and probably deserves the single symbol token. Also, the Logical And appears mostly in conditionals where the `==' mostly does. It just `looks conditional'. ~ I vote for [3], given the prior existence of an appropriate keyword. You are entitled to your opinion. ~ Karl W. Z. Heuer (ihnp4!bentley!kwh), The Walking Lint (Root Boy) Jim Cottrell <rbj@cmr>
bright@dataioDataio.UUCP (Walter Bright) (04/09/86)
In article <687@bentley.UUCP> kwh@bentley.UUCP (KW Heuer) writes: >[3] Someone proposed using "a+(volatile)(b+c)". I think this is workable, >though not quite the same meaning as volatile applied to a simple variable. Not even close! 'volatile' means to the compiler: o The value of the variable can change anytime (asynchronously), and the value can be read anytime (asynchronously) independently of the executing program (such as an I/O port register). The ramifications of this are from the compiler's perspective: 1) Do not remove redundant reads of the variable. 2) Do not remove dead assignments to the variable. Producing another definition which means: o Do not reorder the expression. is a totally distinct meaning. I'm totally against such overloading of the meaning of 'volatile'. It makes about as much intuitive sense as: "a+(while)(b+c)" which is also easily implementable, but very confusing. For all of those of you out there who were confused by the two distinct meanings of the keyword 'static', speak up! (By the way, the meanings of static are: 1. If outside the scope of a function, do not make the symbol global. 2. If inside the scope of a function, allocate storage in the data segment instead of on the stack. ) -- Row well, and live. --
greg@utcsri.UUCP (Gregory Smith) (04/10/86)
In article <2447@brl-smoke.ARPA> rbj@icst-cmr (Root Boy Jim) writes: >~ (OOE = Order-Of-Evaluation.) >~ [1] "()" is worse. The code generator should NOT have to assume all >~ parens specify OOE. In the example given it looks intuitive (since I could >~ write "a+b+c" for dont-care, obviously "(a+b)+c" or "a+(b+c)" reflect >~ intended OOE), but it's not true in general. Also, it's already been >~ observed that expanded macros often have extraneous parens. > >Which serve to specify OOE. I think it slightly weird that K&R allowed >rearranging OOE for associative operators, but mostly it doesn't hurt. Parentheses DO NOT SPECIFY ORDER OF EVALUATION ( at least not in this sense). They are used to override the bindings of operators. In compiler terms, this means that ()'s are used to control the shape of the parse tree, but they do not otherwise affect the order of the code generated for it. Consider that ?: groups right-to-left [ meaning a?b:c?d:e == a?b:(c?d:e)] but is evaluated left to right: 'a' is always done first. Don't look at K&R page 215 - it is wrong on this point. Pg. 49 is correct. >Anyone for a reverse polish notation C spec? *No*. Try Forth. You'll soon agree. -- "If you aren't making any mistakes, you aren't doing anything". ---------------------------------------------------------------------- Greg Smith University of Toronto UUCP: ..utzoo!utcsri!greg
larry@cca.UUCP (Laurence Schmitt) (04/11/86)
> It is debatable whether `&' or `&&' is used more commonly. The Bitwise ----------- > And (&) is certainly a more familiar construct and probably deserves ---------------------------------------------- > the single symbol token. Also, the Logical And appears mostly in > conditionals where the `==' mostly does. It just `looks conditional'. ----------------- This man has been coding C too long! {;-) -- Larry Schmitt Computer Corporation of America larry@cca 4 Cambridge Center decvax!cca!larry Cambridge, MA 02142 (617)-492-8860
franka@mmintl.UUCP (Frank Adams) (04/14/86)
In article <687@bentley.UUCP> kwh@bentley.UUCP writes: >In article <2323@brl-smoke.ARPA> HARGED%ti-eg.csnet@CSNET-RELAY.ARPA writes: >>Folks, no two ways about it: "a + +(b + c)" looks very strange (it looks >>like a typographical error), particularly when it is *required* to >>accomplish what most people intuitively assume "a + (b + c)" will >>accomplish. From a human factors standpoint, this proposal is a >>disaster. Let me repeat my suggestion that "a + [b + c]" be used for this purpose. It isn't *obvious* what it is intended to mean differently from "a + (b + c)", but it at least doesn't look like a typographical error. Use of brackets of arbitrary shape or size has a long mathematical tradition. Frank Adams ihnp4!philabs!pwa-b!mmintl!franka Multimate International 52 Oakland Ave North E. Hartford, CT 06108
rbj%icst-cmr@smoke.UUCP (04/16/86)
> In article <2447@brl-smoke.ARPA> rbj@icst-cmr (Root Boy Jim) writes: > >~ (OOE = Order-Of-Evaluation.) > >~ [1] "()" is worse. The code generator should NOT have to assume all > >~ parens specify OOE. In the example given it looks intuitive (since I could > >~ write "a+b+c" for dont-care, obviously "(a+b)+c" or "a+(b+c)" reflect > >~ intended OOE), but it's not true in general. Also, it's already been > >~ observed that expanded macros often have extraneous parens. > > > >Which serve to specify OOE. I think it slightly weird that K&R allowed > >rearranging OOE for associative operators, but mostly it doesn't hurt. > > Parentheses DO NOT SPECIFY ORDER OF EVALUATION ( at least not in this > sense). They are used to override the bindings of operators. In compiler > terms, this means that ()'s are used to control the shape of the parse > tree, but they do not otherwise affect the order of the code generated for it. Which to my mind is OOE. At least when we're talking simple variables. True, if `a', `b', & `c' are expressions (funxion calls in particular) any funxion might be called first. In all other cases except associative operators specify OOE by changing the bindings of the operators. I don't understand the distinxion you are drawing. > Consider that ?: groups right-to-left [ meaning a?b:c?d:e == a?b:(c?d:e)] > but is evaluated left to right: 'a' is always done first. Don't look at > K&R page 215 - it is wrong on this point. Pg. 49 is correct. > > >Anyone for a reverse polish notation C spec? > > *No*. Try Forth. You'll soon agree. Hey, why not? Let's get rid of the distinxion between `statements' and expressions. Then we don't need an IF. Just use `?:'. <exp> ? <true> : <false> > Greg Smith University of Toronto UUCP: ..utzoo!utcsri!greg (Root Boy) Jim Cottrell <rbj@cmr>
jsdy@hadron.UUCP (Joseph S. D. Yao) (04/17/86)
In article <951@dataioDataio.UUCP> bright@dataio.UUCP (Walter Bright writes: >For all of those of you out there who were confused by the two distinct >meanings of the keyword 'static', speak up! > 1. If outside the scope of a function, do not make the symbol global. > 2. If inside the scope of a function, allocate storage in > the data segment instead of on the stack. The single meaning of static is: allocate storage in the appropriate (text code or data) segment and make the symbol not accessible outside this module. When used inside a function, "module" means "function"; when used outside, "module" means "file". [Maybe these are a differ- ent two distinct meanings.] -- Joe Yao hadron!jsdy@seismo.{CSS.GOV,ARPA,UUCP}
john@wvlpdp (04/17/86)
I vote against unary + John A. Ebersold World Video Library ihnp4!convex!ctvax!trsvax!doc!wvlpdp!john 2747 Airport Freeway Fort Worth, Texas 76111
randy@utcsri.UUCP (Randall S. Becker) (04/20/86)
In article <1245@mmintl.UUCP> franka@mmintl.UUCP (Frank Adams) writes: > >In article <687@bentley.UUCP> kwh@bentley.UUCP writes: >>In article <2323@brl-smoke.ARPA> HARGED%ti-eg.csnet@CSNET-RELAY.ARPA writes: >>>Folks, no two ways about it: "a + +(b + c)" looks very strange (it looks >>>like a typographical error), particularly when it is *required* to >>>accomplish what most people intuitively assume "a + (b + c)" will >>>accomplish. From a human factors standpoint, this proposal is a >>>disaster. > >Let me repeat my suggestion that "a + [b + c]" be used for this purpose. >It isn't *obvious* what it is intended to mean differently from "a + (b + c)", >but it at least doesn't look like a typographical error. Use of brackets >of arbitrary shape or size has a long mathematical tradition. > Forgive me for asking, but what is meant by a + +(b + c)? Common interpretations: a + abs(b + c) (not likely) a + (b + c) (likely, in my opinion) Now, if unary plus is equivalent to the generic abs() operator then why not use abs()? I know, C doesn't have generics. I would argue that the meaning is exactly the second case. What does + ( -1 ) mean? -1. How about - + - 1? 1. Obviously, +1 had better be 1. The use of unary '+' as a no sign change operator is the accepted definition in some languages developed at the University of Toronto. Randy -- Randall S. Becker Usenet: ..!utcsri!randy CSNET: randy@toronto
greg@utcsri.UUCP (Gregory Smith) (04/21/86)
In article <951@dataioDataio.UUCP> bright@dataio.UUCP (Walter Bright writes: >In article <687@bentley.UUCP> kwh@bentley.UUCP (KW Heuer) writes: >>[3] Someone proposed using "a+(volatile)(b+c)". I think this is workable, >... I'm totally against such overloading of >the meaning of 'volatile'. It makes about as much intuitive sense as: > "a+(while)(b+c)" >which is also easily implementable, but very confusing. How about "a+(do)(b+c)", or "a+(!break)(b+c)" ? ? ? :-) (-: :-) (-: -- "If you aren't making any mistakes, you aren't doing anything". ---------------------------------------------------------------------- Greg Smith University of Toronto UUCP: ..utzoo!utcsri!greg
friesen@psivax.UUCP (04/21/86)
In article <2591@utcsri.UUCP> randy@utcsri.UUCP (Randall S. Becker) writes: > >Forgive me for asking, but what is meant by a + +(b + c)? > Common interpretations: > a + abs(b + c) (not likely) > a + (b + c) (likely, in my opinion) > The answer is *neither*. In the proposed 'C' standard it means register tmp; (tmp = b + c, a + tmp) except that tmp never actually exists. This is what all the fuss is about. Some people think this is a poor idea. The problem this is intended to solve is that the 'C' language permits a + (b + c) to be evaluated in *any* order, even [a + b] + c. -- Sarima (Stanley Friesen) UUCP: {ttidca|ihnp4|sdcrdcf|quad1|nrcvax|bellcore|logico}!psivax!friesen ARPA: ttidca!psivax!friesen@rand-unix.arpa
trent@cit-vax.UUCP (04/23/86)
Organization : California Institute of Technology Keywords: [this space for rent] Has anyone considered a construct such as: #forceorder <expr> to signal the compiler that you really want the expression evaluated as the parens in the statement specify? I don't see why you should have to use a completely new construct (like a unary +) to give instructions to the compiler. We already know how to do that. Any thoughts? -- ../ray\.. (trent@csvax.caltech.edu) "The above is someone else's opinion only at great coincidence"