Path: utzoo!attcan!uunet!cs.utexas.edu!rice!titan.rice.edu!preston
From: preston@titan.rice.edu (Preston Briggs)
Newsgroups: comp.lang.misc
Subject: Re: := versus ==
Message-ID: <1990Aug2.170110.28208@rice.edu>
Date: 2 Aug 90 17:01:10 GMT
References: <=L-4T-A@ggpc2.ferranti.com> <17559:Aug101:50:5290@kramden.acf.nyu.edu> <7H+4AM6@xds13.ferranti.com>
Sender: news@rice.edu (Priestess to the News Gods)
Organization: Rice University, Houston
Lines: 40

>In article <17559:Aug101:50:5290@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:

About his language Q

>>   a == b is for comparison. Its value is 1 if they're equal, 0 if not.
>>   a := b is for assignment. It sets a to b and has value a.
>>   a = b is for assignment. It sets a to b and has no value.


In article <7H+4AM6@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes:

About PL/M

>Interestingly, the PL/M-286 users guide follows this section with a BIG
>BLACK BOX warning that:

>	a = (x := x + 4) + y * y + x

>is ambiguous and "The results depend on too many factors, e.g. the
>optimisation level you specify to the compiler."

It would be nicer if you didn't allow side-effects (assignments, 
among other things) in expressions, particularly for optimizers!

Normally, we say: 

	x + y = y + x	where x and y are arbitrary expressions.

With C, Q, and PL/M, this doesn't hold.
E.g.,

	(i := 1) + i is not always equal to i + (i := 1)

Same problems with ++ and -- in C.
Same problem in lots of languages where people write functions
with side-effects.

-- 
Preston Briggs				looking for the great leap forward
preston@titan.rice.edu