Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!umich!samsung!cs.utexas.edu!uunet!mcsun!sunic!tut!tukki!sakkinen
From: sakkinen@tukki.jyu.fi (Markku Sakkinen)
Newsgroups: comp.lang.misc
Subject: Re: NOT Educating FORTRAN programmers to use C
Message-ID: <2806@tukki.jyu.fi>
Date: 23 Jan 90 16:38:43 GMT
References: <12950@cbnewsc.ATT.COM> <14199@lambda.UUCP> <4540@scolex.sco.COM>
Reply-To: sakkinen@jytko.jyu.fi (Markku Sakkinen)
          SAKKINEN@FINJYU.bitnet (alternative)
Organization: University of Jyvaskyla, Finland
Lines: 76

In article <4540@scolex.sco.COM> seanf@sco.COM (Sean Fagan) writes:
>In article <14199@lambda.UUCP> jlg@lambda.UUCP (Jim Giles) writes:
>> ... [a lot deleted]
 [about order of evaluation]
>>Fortran (pascal, Modula2, ADA, ...) lets me do so
>>with parenthesis - C forces me to introduce temporary variables and
>>_hope_ that the optimizer doesn't actually do a store/load.
>
>Read your standards.  ANSI-C (a reality, now) has requirements for
>order-of-evaluation, much to my chagrin. [...]
                      ^^^^^^^^^^^^^^^^^^
I hope the standard has left at least one other anti-mathematic trick
still intact for your enjoyment, namely that a leading zero changes
the meaning of a numeric literal (to octal).

> ...
>>[...]  The optimization
>>that you want the compiler to do without is called "common subexpression
>>elimination".  It is important that your compiler know how to do this
>>optimization even if you do have a '+=' operator.  I wouldn't ever buy
>>a compiler which didn't have this capability.  A compiler without this
>>capability is somewhat behind the state-of-the-art anyway (by about 30
>>years).
>
>	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.

I would certainly be puzzled by a Fortran compiler that accepted
and even optimised C code :-) (It is easy enough to imagine the
corresponding Fortran statement.)
The Fortran standard does not specify the evaluation order between the
left and right hand sides of an assignment, nor between the operands
of a binary operator. Therefore, the optimisation you suggest does in fact
correspond to one possible evaluation order - since indexing an array
by a simple variable cannot cause any side effects.

If the function foo causes side effects that make the total effect
of the statement dependent on the actual order of evaluation,
then the statement is incorrect (isn't it, language lawyers?).
Anyway, the problem does not come from the optimisation.
(The Fortran standard is principally permissive: some compiler builder
might well try to make even a large class of slightly incorrect programs
to behave "as the programmer probably intended".)

I think that the modifying assignment operators of Algol 68 and C are
convenient, especially when the expression that you then need not write
twice is complicated and error-prone. However, they are not very general.
They cannot simplify expressions like
   x[i] = y / x[i]
   x[i] = e * x[i] + z
At least in the Mode language designed
and implemented by Juha Vihavainen (University of Helsinki) one can refer
to the left-hand side of assignment on the right thus:
   x(i) := y / *
   x(i) := e * * + z
Lexically this happens to be yet another overloading of '*',
something else could have been chosen.

I think this idea would fit even more naturally
into a language with good old assignment _statements_ instead of assignment
_expressions_: expressions can be nested and the referent of the l.h.s.
reference less clear: e.g.
   x(i) := (y(j) := * + z) + fun (*);

Markku Sakkinen
Department of Computer Science
University of Jyvaskyla (a's with umlauts)
Seminaarinkatu 15
SF-40100 Jyvaskyla (umlauts again)
Finland