[448] in Coldmud discussion meeting

root meeting help first first in chain previous in chain previous next next in chain last in chain last

Re: assignments change (fix)

daemon@ATHENA.MIT.EDU (Fri Sep 23 20:25:53 1994 )

To: coldstuff@MIT.EDU
In-Reply-To: Your message of Fri, 23 Sep 94 15:28:23 -0400.
             <9409231928.AA19061@m2-225-9.MIT.EDU> 
Date: Fri, 23 Sep 94 20:24:05 EDT
From: George Heintzelman <georgeh@MIT.EDU>


As a usual lurker here, I'd like to stick my .02 in on the matter of 
assignment and while loops. In reading code, I find:

while (1) {
	a= foo();
	if (test(a))
	   break;
	endif
	{ Other stuff}
}

to be distinctly more difficult to understand on a first reading than

while (test(a=foo())) {
	Other stuff
}

And not just because of the lines of code. In order to understand the upper 
loop, you have to read into the loop and find the break, to understand when 
the loop will terminate. Sometimes you don't even CARE what the loop really 
does, you just want to know when it terminates, in fact. 

I'm a physicist by trade, and in that trade you have to read a lot of FORTRAN 
code. FORTRAN, being a REALLY antiquated language, encourages constructs such 
as the first, with lots of GOTO's and things instead of break statements, but 
the effect is the same.... And I know that I don't like it. I would much 
prefer reserving the break statement for cases where you really want the loop 
to terminate extraordinarily, as in:

i = 0;
while (i < lines) {
	catch ~eof {
		.read_line()
	} handler {
		// Ooops! End of file!!
		.send_error_message_intelligently()
		break;
	}
i++
}

So I guess I'm arguing for some form of assignment-as-expression. Perhaps := 
is an assignment-as-expression operator while retaining = as an 
assignment-as-command operator? I'm not sure I would necessarily do this, it 
does seem to contradict the impulse to keep the language as streamlined as 
possible, but it may be something to think on. Though I admit to generally 
agreeing with Greg's dislike of side effects, I think allowing it in this one 
limited case isn't going to cause it to propagate too far.

George Heintzelman
georgeh@mit.edu