dandb@cmu-cs-k.ARPA (Dean Rubine) (12/11/84)
Here's one I always wanted: ->=
For example:
struct foo { /* stuff */ struct foo *next } *p;
for(p = whatever; p != NULL; p ->= next)
/* look at p->stuff */
Dean Rubine Arpa: Rubine@cmu-cs-a, Rubine@cmu-cs-k
The major effect that the breakup of ATT has had on
me is that I no longer know my uucp address.jack@vu44.UUCP (Jack Jansen) (12/12/84)
Dean Rubine asked for a ->= operator, but this
is quite impossible (if you try to keep the language
clean, of course). -> isn't an operator, it's a syntactical
construct, like . or [expr].
Also, it would be awfull to implement. In a statement
p ->= next
you would have to keep the type of 'p' around, 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'?).
I hope this isn't implemented. It doesn't do a lot of good,
and it's clearly a very dirty feature.
--
Jack Jansen, {seismo|philabs|decvax}!mcvax!vu44!jack
or ...!vu44!htsa!jackquiroz@rochester.UUCP (Cesar Quiroz) (12/13/84)
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
ron@brl-tgr.ARPA (Ron Natalie <ron>) (12/17/84)
> Dean Rubine asked for a ->= operator, but this > is quite impossible (if you try to keep the language > clean, of course). -> isn't an operator, it's a syntactical > construct, like . or [expr]. Sorry, my book says that "->", ".", and "[]" are the primary expression operators and have the highest priority. > Also, it would be awfull to implement. In a statement > p ->= next > you would have to keep the type of 'p' around, 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'?). I don't understand this at all. Keep the type of 'p' around? This makes litle sense. You better keep the type of something you are storing into around, regardless of the type of expression. I agree, it sucks. Nowhere does it define assignment-operator as being <generic-operator>=. It doesn't even say <binop>=. -Ron
david@ukma.UUCP (David Herron, NPR Lover) (12/18/84)
Jack Jansenn at the Retarded Programmers Home suggests that -> is not
an operator. In the Ansi Draft Standard for C (our copy is dated Oct, 17)
-> is an operator, as well as '.' and [] and () and (cast) and sizeof.
-----------------------------------------
David Herron; ARPA-> "ukma!david"@ANL-MCS
(Try the arpa address w/ and w/o the quotes, I have had much trouble with both.)
UUCP-> unmvax -----------\
UUCP-> research ----------\_______ {anlams,anl-mcs} --\
UUCP-> boulder -----------/ >-!ukma!david
UUCP-> decvax!ucbvax ----/ cbosgd!hasmed!qusavx --/
(The usual warning about having no opinions). "I read banned books."
Lets see how long it takes for the NSA boys to start chasing me:
"The NSA is the CIA is the FBI is the KGB".bjpt@mulga.OZ (Benjamin Thompson) (12/20/84)
A bit of history : Dean Rubine suggested a "->=" operator, to which the response has been mostly negative. Ron@brl-tgr mentioned a more general "operator" (<binop>=). The idea of <binop>= strikes me as a very good and very easy to implement idea. Consider that X <binop>= Y; (call this form 1) is exactly the same statement as X = X <binop> Y; (call this form 2) Given that <binop> is a legal operator, all C compilers already have code to compile form 2. All we have to do now is modify the compiler(s) to convert form 1 to form 2. This should be utterly trivial, and allows us to add a nice bit of generality to C.
bsa@ncoast.UUCP (Brandon Allbery) (12/22/84)
It's been stated that allowing x->=y would produce an RHS that was not
anything usual, and comments about Pascal `with' statements were made.
On this topic... I've noticed that one of the hidden error messages in
our compiler makes it seem that under certain circumstances, you could
use exactly this form in an ordinary expression: specifically,
foo(bar)
int bar;
{
struct
{
int i_val;
float i_something;
}
obj;
i_val = bar;
}
or its equivalent in the opposite direction, as long as you didn't have
more than one variable which was supposed to use that struct member (shades
of COBOL! :-). Maybe I read it wrongly... but maybe this isn't the problem
it might be.
I've considered the usefulness of both with blocks and ->= ; I can see
uses for both, but not many. And for ->= , the problem discussed with
&& vs. ^^ applies: += , et al., are signals to the compiler to optimize.
I'm not sure that x=x->g (equiv. x=(*x).g, or x = (*x)+offset) can really
be optimized that much, so ->= is simply shorthand. Maybe a preprocessor?
(As for with: At least the syntax would be regular: with (var) stmts .
That doesn't mean I like it.)
--bsa
--
Brandon Allbery @ decvax!cwruecmp!ncoast!bsa (..ncoast!tdi1!bsa business)
6504 Chestnut Road, Independence, Ohio 44131 (216) 524-1416
<<<<<< An equal opportunity employer: I both create and destroy bugs :-) >>>>>>gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (12/26/84)
> X <binop>= Y; (call this form 1) > is exactly the same statement as > X = X <binop> Y; (call this form 2) Not quite. Another part of the semantics is that "X" is evaluated ONLY ONCE. So a na"ive translation of form 1 to form 2 won't work.
lars@myab.UUCP (Lars Pensj|) (12/26/84)
x I like the idea of a assignment operator in the form X <binop>= Y; (but I am not sure i want it implemented in the language C). Some operators will be redundant, like ',='. I also question the usefulness of '.='. I can see two purposes of this <binop>= operator: 1. More dense, compact or readable programs. 2. Make more efficient programs when the compiler isn't smart enough to see this himself. Point 1 can be somewhat satisfied using the preprocessor. In this case, I am more interested in point 2. Why not expand this to the more general case where X = ... X ...; can be rewritten to an expression where the address of X only needs to be calculated once. The syntax for this could be let X = expr in ... X ...; for example let x = a[j*10+i] in x = func(x); This example shows a case where the compiler could not do this optimization if 'j' or 'i' was global variables. Another syntactic form could be X = expr @ ... X ...; This construction already exists in some languages.
ed@mtxinu.UUCP (Ed Gould) (12/27/84)
> ... > Consider that > X <binop>= Y; (call this form 1) > is exactly the same statement as > X = X <binop> Y; (call this form 2) > ... But, of course, form 1 and form 2 are not quite the same thing. The semantic difference is that in form 1 X is evaluated once, and it's evaluated twice in 2. If there are side effects, this can cause great damage to the algorithm. So, just translating 1 into 2 isn't right. -- Ed Gould {ucbvax,decvax}!mtxinu!ed
sde@Mitre-Bedford (12/28/84)
>> >>I can see two purposes of this <binop>= operator: >> >>1. More dense, compact or readable programs. >> ------>>2.Make more efficient programs when the compiler isn't smart enough >> to see this himself. >>... >>In this case, I am more interested in point 2. Why not expand this >>to the more general case where >> >>X = ... X ...; >>can be rewritten to an expression where the address of X only needs to >>be calculated once. The syntax for this could be >> >>let X = expr in ... X ...; >>for example >> >>let x = a[j*10+i] in x = func(x); >>This example shows a case where the compiler could not do this >>optimization if 'j' or 'i' was (sic) global variables(sic). Another >>syntactic form could be >> >>X = expr @ ... X ...; >>This construction already exists in some languages. I shudder to suggest this, but if you want that effect, how about: register float *y; ... *(y=&a[...]) = func( *y ); David sde@mitre-bedford
andrew@orca.UUCP (12/28/84)
[]
"The idea of <binop>= strikes me as a very good and very easy
to implement idea. Consider that
X <binop>= Y; (call this form 1)
is exactly the same statement as
X = X <binop> Y; (call this form 2)
"Given that <binop> is a legal operator, all C compilers
already have code to compile form 2. All we have to do now is
modify the compiler(s) to convert form 1 to form 2. This
should be utterly trivial, and allows us to add a nice bit of
generality to C."
This isn't really true. For example, the following two statements have
different meanings:
X[6*rand()] *= Y;
X[6*rand()] = X[6*rand()] * Y;
A programmer who codes the first form would not be satisfied if the
compiler were to produce the second form.
-- Andrew Klossner (decvax!tektronix!orca!andrew) [UUCP]
(orca!andrew.tektronix@csnet-relay) [ARPA]bjpt@mulga.OZ (Benjamin Thompson) (12/29/84)
In article <6771@brl-tgr.ARPA> gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) writes: >> X <binop>= Y; (call this form 1) >> is exactly the same statement as >> X = X <binop> Y; (call this form 2) > >Not quite. Another part of the semantics is that "X" is evaluated >ONLY ONCE. So a naive translation of form 1 to form 2 won't work. Quite - I forgot about nifty little lvalues like *++x. Even so, I should imagine there is already code in the compilers to handle this type of problem for the <binop>= operators C already has. I think altering a C compiler to allow more general <binop>='s should still be fairly trivial. operators we already have
david@ukma.UUCP (David Herron, NPR Lover) (12/31/84)
> I shudder to suggest this, but if you want that effect, how about: > > register float *y; > ... > *(y=&a[...]) = func( *y ); > > David sde@mitre-bedford Good thing you shudder to suggest that. Won't work with the 4.2 vax compiler. The 4.2 compiler evaluates any function calls in an expression BEFORE anything else. This is so the code will work. (Don't remember the exact reason but recall that it had to do with the saving of r0 and r1 correctly). So (in your code) func will be called with the contents of whatever random place y points at.....possibly resulting in a hard to find bug. Now, if you want it all in one line of code: y=&a[...], *y = func( *y ); (Ain't C fun?) David Herron
atbowler@watmath.UUCP (Alan T. Bowler [SDG]) (01/18/85)
Just a bit of history. The original B compiler (the one that evolved
into the Unix C compiler), had more assignment operators.
Back then the form was =<binop> (i.e. =+ =- =& etc).
The operators ===, =<, =>, =<=, and =>= were present.
They were indpendantly dropped by both Waterloo (in subsequent B compilers),
and by Bell Labs in the evolving C compiler. The reason was simply
that they were never used and made for language clutter.
The is of course the small point that trying to support every
case of <binop>= means that "<=" becomes ambiguous.
(i.e. a<=b can then mean "set a to 0 if the current value of a is
greater than or equal to b)robert@gitpyr.UUCP (Robert Viduya) (01/27/85)
> > and why not add <unop>= , too? > > i -= ; > > p &= ; > > q *= ; Say what??? -- Robert Viduya Office of Computing Services Georgia Institute of Technology, Atlanta GA 30332 Phone: (404) 894-4669 ...!{akgua,allegra,amd,hplabs,ihnp4,masscomp,ut-ngp}!gatech!gitpyr!robert ...!{rlgvax,sb1,uf-cgrl,unmvax,ut-sally}!gatech!gitpyr!robert
grayson@uiucuxc.UUCP (02/01/85)
and why not add <unop>= , too? i -= ; p &= ; q *= ;
sjr@snow.UUCP (Stephen J. Rumsby) (02/04/85)
One I can't remember being mentioned so far :- ->= Then you can use p ->= next; for chasing down lists!
mark@rtech.ARPA (Mark Wittenberg) (02/12/85)
> One I can't remember being mentioned so far :- > > ->= > > Then you can use > > p ->= next; > > for chasing down lists! I always thought it would be sort of nice to have <=> as "swap": thus a <=> b; replaces some_type c; c = a; a = b; b = a; useful since "some_type" can't be decided dynamically. Also on some machines and for some "some_type" this can be done efficiently, even atomically, eg, register char *a, *b; a <=> b; on a 68000 is one instruction. Mark Wittenberg Relational Technology, Inc. ucbvax!mtxinu!rtech!mark zehntel!rtech!mark
mark@rtech.ARPA (Mark Wittenberg) (02/12/85)
> I always thought it would be sort of nice to have > <=> > as "swap": thus > a <=> b; > replaces > some_type c; > c = a; > a = b; > b = a; > useful since "some_type" can't be decided dynamically. > Also on some machines and for some "some_type" this > can be done efficiently, even atomically, eg, > register char *a, *b; > > a <=> b; > on a 68000 is one instruction. > > Mark Wittenberg > Relational Technology, Inc. > ucbvax!mtxinu!rtech!mark > zehntel!rtech!mark Well, thanks to the miracle of modern network delay, I see that someone else has already suggested this operator, although I didn't see the proposed syntax. You can't win them all. /mark
berry@zinfandel.UUCP (Berry Kercheval) (02/12/85)
In article <141@rtech.ARPA> mark@rtech.ARPA (Mark Wittenberg) writes: >I always thought it would be sort of nice to have > <=> >as "swap" [...] Well, Icon (I, know, I know, it's not C) has such an operator called ":=:" (Icon uses the ":=" for assignment) I would like to see the operator ':-)'. I'm taking bets on what it will mean (:-) -- La musique est une science qui veut qu`on rit et chante et dance. -- Guillaume de Machaut Berry Kercheval Zehntel Inc. (ihnp4!zehntel!zinfandel!berry) (415)932-6900 (kerch@lll-tis.ARPA)
roy@phri.UUCP (Roy Smith) (02/16/85)
> I would like to see the operator ':-)'. I'm taking bets on what > it will mean (:-) Clearly, it means "this assignment is a joke", as in: int i; struct foo bar(); i :=) bar; (*i)("baz"); -- The opinions expressed herein do not necessarily reflect the views of the Public Health Research Institute. {decvax,ihnp4}!vax135!timeinc\ >!phri!roy (Roy Smith) {allegra,rocky2}!cubsvax/
johnl@ima.UUCP (02/20/85)
>I would like to see the operator ':-)'. I'm taking bets on what >it will mean (:-) Ah, that's clear enough. You've defined the "doesn't get" operator. For example: a = b; /* a gets b */ a :-) b; /* a doesn't get b */ This tells the optimizer that a and b have nothing to to with each other. The etymology dates from the time that :-) was introduced on Usenet for the benefit of people who don't get jokes. John Levine, ima!johnl
jss@sjuvax.UUCP (J. Shapiro) (02/21/85)
[Aren't you hungry...?] How about ?=, for those of you with a compiler which supports entropy? Jon Shapiro