lvc@danews.UUCP (04/16/87)
I am very dissatisfied with unary plus in the ANSI C. Here are two possible replacements, both of which might not work, but what the heck. The first is to use a special cast called (eval) (or some other appropriate word). It would be used like this: x = (eval)(a + b) + c; In this statement the sum 'a + b' would be computed first, then that would be added to 'c'. x = (eval)(a * b) * (eval)(c * d) Here the products 'a * b' and 'c * d' would be computed, and then they would be multiplied together. (messy huh?) Cast already has the correct precedence for this to work (no?). Furthermore, casts are already in C language. Does anyone see a problem with this approach? Is associativity of cast a problem? The second method I thought of on the way to work this morning, so its less clear to me that it would work and be useful. Instead of using () to separate the operands to be evaluated, we can use [] instead. For example: x = [a + b] + c; and x = [a * b] * [c * d]; The nice thing about this is that it is visually appealing (at least to me), [] has the highest precedence in C along with () and -> and . The problems I see with it are that existing compilers may have to change radically for this work, and secondly, it solves a somewhat different problem than was originally meant to be solved (ie grouping of paren- thesis). -- Larry Cipriani, AT&T Network Systems, Columbus OH, (614) 860-4999
jss@hector.UUCP (04/19/87)
In article <489@danews.ATT.COM> lvc@danews.UUCP writes: > >I am very dissatisfied with unary plus in the ANSI C. People keep saying this, but it is unclear whether they don't like having unary plus or they don't like using it for controlling order of evaluation. As has been pointed out before, unary plus was added for other reasons (mainly that atoi accepts "+1", but "x= +1" was not legal.) Having made the decision to add unary plus anyway, it was decided to make it do double duty. While other alternatives may have virtues, they all have the significant drawback that they require further additions to the grammar, and gain no added functionality. I would also point out that compiler options and the meaning of specific #pragmas are outside the scope of the standard. (As a sociological aside, I think we are seeing the "Bicycle Shed Phenomena". The tendency noted by "Parkinson" for discussions to focus on modest issues that are easy to understand rather than big issues which aren't.) Jerry Schwarz [ not a member of the ANSI Comittee ]
edw@ius2.cs.cmu.edu (Eddie Wyatt) (04/19/87)
Comment: the ANSI proposed unary + has the added semantic of enforcing parenthesis ordering. Question: does the unary - have the added semantics of enforcing parenthesis ordering? If so, would expressions of the form -(x - y) not get optimized to y - x? If not, doesn't this add some non-orthogonality to the the unary + and -? -- Eddie Wyatt They say there are strangers, who threaten us In our immigrants and infidels They say there is strangeness, too dangerous In our theatres and bookstore shelves Those who know what's best for us- Must rise and save us from ourselves Quick to judge ... Quick to anger ... Slow to understand... Ignorance and prejudice and fear [all] Walk hand in hand. - RUSH
henry@utzoo.UUCP (Henry Spencer) (04/20/87)
> Comment: the ANSI proposed unary + has the added semantic of enforcing > parenthesis ordering. > > Question: does the unary - have the added semantics of enforcing parenthesis > ordering? In at least one draft it did; ugh. Fortunately, it doesn't now. > If not, doesn't this add some non-orthogonality to the the unary + and -? Well, yeah, but orthogonality is in the eye of the beholder. The properties of binary + and - are distinctly different (e.g. - is not associative), so expecting orthogonality from the unary operators may be a bit much. If you want real orthogonality, consider something that occurred to me some years ago: the "right" meaning of unary + is "absolute value"! (Yes, I do realize that there are practical reasons not to do this...) -- "If you want PL/I, you know Henry Spencer @ U of Toronto Zoology where to find it." -- DMR {allegra,ihnp4,decvax,pyramid}!utzoo!henry
jeff@slovax.UUCP (Jeff Loucks) (04/20/87)
in article <489@danews.ATT.COM>, lvc@danews.ATT.COM (Larry Cipriani) says: > I am very dissatisfied with unary plus in the ANSI C. ... > The first is to use a special cast called (eval) (or > some other appropriate word). It would be used like this: > > x = (eval)(a + b) + c; > > In this statement the sum 'a + b' would be computed first, > then that would be added to 'c'. > > x = (eval)(a * b) * (eval)(c * d) > > Here the products 'a * b' and 'c * d' would be computed, > and then they would be multiplied together. (messy huh?) > > Cast already has the correct precedence for this to > work (no?). Furthermore, casts are already in C language. > > Does anyone see a problem with this approach? > Is associativity of cast a problem? I like this idea. For one, it deals with the context of the expression, not the content. The purpose is to communicate to the compiler that one portion of an expression should be evaluated first. The unary '+' will do the same, but at the expense of creating a compiler directive disguised as an operator. All other arithmetic operators are subject to optimization. Why not the unary '+' ??? Because it's a special case !!! The unary '+' is needed as just that -- the other half of unary '-'. It should be subject to the same compiler interpretation. if -( a - b ) + z can become z + b - a { evaluated left to right } why can't +( a -b ) + z become z + a - b { evaluated left to right } ??? Let's use compiler directives that are distinct from arithmetic operators. It doesn't mess up the language with special cases that confuse the novice and confound the compiler writter. Thanks for your time. ---------------- uw-beaver!tikal!slovax!jeff (jeff loucks) ----------------- terrorist cryptography DES drugs cipher secret decode NSA CIA NRO IRS coke crack pot LSD russian missile atom nuclear assassinate libyan RSA infiltrate smuggle (suck it up there NSA !!) (really now, is this any way to act ???) ----------------------------------------------------------------------------- -- ---------------- uw-beaver!tikal!slovax!jeff (jeff loucks) ----------------- terrorist cryptography DES drugs cipher secret decode NSA CIA NRO IRS coke crack pot LSD russian missile atom nuclear assassinate libyan RSA infiltrate smuggle (suck it up there NSA !!) (really now, is this any way to act ???) -----------------------------------------------------------------------------
henry@utzoo.uucp (04/21/87)
> Comment: the ANSI proposed unary + has the added semantic of enforcing > parenthesis ordering. > > Question: does the unary - have the added semantics of enforcing parenthesis > ordering? In at least one draft it did; ugh. Fortunately, it doesn't now. > If not, doesn't this add some non-orthogonality to the the unary + and -? Well, yeah, but orthogonality is in the eye of the beholder. The properties of binary + and - are distinctly different (e.g. - is not associative), so expecting orthogonality from the unary operators may be a bit much. If you want real orthogonality, consider something that occurred to me some years ago: the "right" meaning of unary + is "absolute value"! (Yes, I do realize that there are practical reasons not to do this...) -- "If you want PL/I, you know Henry Spencer @ U of Toronto Zoology where to find it." -- DMR {allegra,ihnp4,decvax,pyramid}!utzoo!henry
jeff@slovax.uucp (04/21/87)
in article <489@danews.ATT.COM>, lvc@danews.ATT.COM (Larry Cipriani) says: > I am very dissatisfied with unary plus in the ANSI C. .. > The first is to use a special cast called (eval) (or > some other appropriate word). It would be used like this: > > x = (eval)(a + b) + c; > > In this statement the sum 'a + b' would be computed first, > then that would be added to 'c'. > > x = (eval)(a * b) * (eval)(c * d) > > Here the products 'a * b' and 'c * d' would be computed, > and then they would be multiplied together. (messy huh?) > > Cast already has the correct precedence for this to > work (no?). Furthermore, casts are already in C language. > > Does anyone see a problem with this approach? > Is associativity of cast a problem? I like this idea. For one, it deals with the context of the expression, not the content. The purpose is to communicate to the compiler that one portion of an expression should be evaluated first. The unary '+' will do the same, but at the expense of creating a compiler directive disguised as an operator. All other arithmetic operators are subject to optimization. Why not the unary '+' ??? Because it's a special case !!! The unary '+' is needed as just that -- the other half of unary '-'. It should be subject to the same compiler interpretation. if -( a - b ) + z can become z + b - a { evaluated left to right } why can't +( a -b ) + z become z + a - b { evaluated left to right } ??? Let's use compiler directives that are distinct from arithmetic operators. It doesn't mess up the language with special cases that confuse the novice and confound the compiler writter. Thanks for your time. ---------------- uw-beaver!tikal!slovax!jeff (jeff loucks) ----------------- terrorist cryptography DES drugs cipher secret decode NSA CIA NRO IRS coke crack pot LSD russian missile atom nuclear assassinate libyan RSA infiltrate smuggle (suck it up there NSA !!) (really now, is this any way to act ???) ----------------------------------------------------------------------------- -- ---------------- uw-beaver!tikal!slovax!jeff (jeff loucks) ----------------- terrorist cryptography DES drugs cipher secret decode NSA CIA NRO IRS coke crack pot LSD russian missile atom nuclear assassinate libyan RSA infiltrate smuggle (suck it up there NSA !!) (really now, is this any way to act ???) -----------------------------------------------------------------------------
dsill@NSWC-OAS.arpa (04/24/87)
Jerry Schwarz <jss@hector..uucp> wrote: >(As a sociological aside, I think we are seeing the "Bicycle Shed >Phenomena". The tendency noted by "Parkinson" for discussions >to focus on modest issues that are easy to understand rather >than big issues which aren't.) Perhaps Mr. Schwarz could be persuaded to disclose some of the "big" issues. I think there are a few of us who would be willing to try to understand them. -Dave Sill dsill@nswc-oas.arpa