Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ames!lll-tis!lll-winken!arisia!quintus!ok
From: ok@quintus.uucp (Richard A. O'Keefe)
Newsgroups: comp.lang.fortran
Subject: Re: function side effects (was: i++, i+=1, i=i+1)
Message-ID: <445@quintus.UUCP>
Date: 20 Sep 88 07:17:42 GMT
References: <3983@h.cc.purdue.edu> <3745@lanl.gov>
Sender: news@quintus.UUCP
Reply-To: ok@quintus.UUCP (Richard A. O'Keefe)
Organization: Quintus Computer Systems, Inc.
Lines: 26

In article <3745@lanl.gov> jlg@lanl.gov (Jim Giles) writes:
>...  I just pointed out that the standard has never contained
>a random number generator and that maybe the constraints (in 6.6 of the
>standard) were the reason why.

There is no reason why the random number generator has to take the form
of a _function_.  The standard could have specified something like
	CALL RNSEED(I)		/* initialise */
	CALL RNUNIF(X)		/* get next random number */
Perhaps someone associated with the F77 standard is reading this newsgroup
and could tell us the real reason.  I suspect that the answer may have more
to do with the standard not specifying integer arithmetic (e.g. not wanting
to specify a generator which requires 32-bit twos complement with no
overflow detection).  Or they may not have wanted to commit the standard to
a generator which might later prove unsatisfactory.

To return briefly to the "update assignment" notation: I suggest that a
notation like <lhs> <op>:= <rhs> is advantageous to both writer and reader.
To the writer:
	if you don't type the <lhs> twice, you've missed a change to
	get it wrong.
To the reader:
	it is *obvious* that the lhs is being updated without having to
	decode a complicated expression.
Never mind whether the <lhs> is evaluated once or twice (in a well-written
program it really shouldn't matter): you only have to _write_ it once and
you only have to _read_ it once.