🚀 go-pugleaf

From article <4540@scolex.sco.COM>, by seanf@sco.COM (Sean Fagan):
> [...]
> 	x[i] = x[i] + foo();
> vs.
> 	x[i] += foo();
> where one or more of x and i are global.  Oops.  If your FORTRAN copmiler
> optimizes that away, you quite probably, have some problems.

If the function evaluation changes either x or i in the above, the Fortran
version of " x[i] = x[i] + foo()" would be illegal!  This is not perfect
either and the Fortran version would have to introduce an intermediate
variable to store the function result.  However, if any of your C programs
rely on the above distinction, it is likely to be a source of errors
anyway.  Most advocates of "structured programming" recommend against
fuctions with side-effects at all.  As a practical matter, such functions
require more careful treatment regardless of language.

This is not to say that I agree with the Fortran restriction.  I think
the above assignment should be legal and the user should be allowed to
control whether optimization is performed or not by declaring whether
the function has side-effects or not.  Neither C nor Fortran currently
has this feature.

> [...]
> Some of Jim's points have merit.  However, he does not really seem to know
> what's available in C compilers today,

True, I don't know the whole C market.  I only know what the C compilers
avaliable to ME are capable of doing.  Further, most C supporters in this
discussion don't seem to know what available Fortran implementations do
(I haven't been limited to 6 char identifiers for over a decade).

> [...]                               nor what the C standard (no longer a
> draft!) says, which kinda hurts his arguments.

Just because C has been approved doesn't mean general availability.
C supporters don't know what Fortran 90 offers either - why should they?
Fortran 90 is on the verge of approval (within a few months most likely)
but it won't be widely available for a while yet.  I don't claim that
your ignorance of Fortran 90 hurts your argument.

J. Giles