Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site rochester.UUCP Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!godot!harvard!seismo!rochester!quiroz From: quiroz@rochester.UUCP (Cesar Quiroz) Newsgroups: net.lang.c Subject: Re: YAAO (yet another assignment operator) Message-ID: <4654@rochester.UUCP> Date: Wed, 12-Dec-84 18:23:06 EST Article-I.D.: rocheste.4654 Posted: Wed Dec 12 18:23:06 1984 Date-Received: Fri, 14-Dec-84 05:38:28 EST References: <209@cmu-cs-k.ARPA> <529@vu44.UUCP> Organization: U. of Rochester, CS Dept. Lines: 78 In a recent article, we are told that > Dean Rubine asked for a ->= operator, but this > is quite impossible (if you try to keep the language > clean, of course). "Impossible" and "Inconvenient" are quite not the same. I feel that the proposed YAAO is perfectly possible to implement (it is even easy to understand), but is not worth the extra effort. More on this below. > -> isn't an operator, it's a syntactical > construct, like . or [expr]. Ok. That still makes it clear that the following rule works: x ->= y means x = (x->y) in the same sense that this rule works: x -> y means (*x).y So, the preceding argument doesn't hold. Moreover, the term 'operator' need not be restricted to 'arithmetic operator' ! In that light, I don't get the message of "->" being of a different substance than "+". > Also, it would be awfull to implement. In a statement > p ->= next > you would have to keep the type of 'p' around, Consider this fragment: /* C code begins */ float x; ... x += 1; /* Back to NetLand */ I hope it is generally agreed that you should better remember the type of x (not to mention its address) until you are done with the assignment expression. Otherwise, you may forget to complain/coerce about the type of the constant 1. I don't see how the proposal would add any particularly hairy state keeping requirement. > and also the > expression on the righthandside would not be an ordinary > expression, neither a lvalue nor a rvalue, but something wierd > (a 'selection expression'?). Here you are right. I concur that this is the problem that makes the addition of the proposed operator inconvenient, it introduces something not very often seen in C: implicit/insufficient qualification. Obviously, the RHS of ->= has to be a structure/union member, but the qualification comes from the LHS (one token away can be too far away!). An additional semantic check would be that the RHS has to be a pointer and the LHS another pointer to the same type, but that only makes sense to me. (Of course, an unrepentant hacker may wish to get the RHS to be any expression that the compiler can map as an offset ...) If this proposal is accepted, a similar argument would call for constructs a la Pascal 'with', or some other device to open the scope of a structure. Although this may be seen as a conceptually useful tool, adding it a posteriori will only weaken the language. > I hope this isn't implemented. It doesn't do a lot of good, > and it's clearly a very dirty feature. I myself could find very nice and portable :-) uses for it, but am not longing for it. It could be interesting to know what compiler writers/maintainers think of the proposals that appear here (or in the mod.* counterpart). It doesn't help if we can foresee that only a minor number of sites will upgrade to a too ambitious standard. Cesar