>optimization, but we all know it "must be allowed". Otherwise, a
What "we all know" isn't necessarily true. Interp #1 is really quite
clear, the answer to your question
do i = 1, n
x = cos (6.5*t) + y
a(i) = a(i) + x
end do
Is if there is a way to determine that the transformation occurred, it
isn't permitted.
Naturally, on nearly any real processor there is always "some" way to
tell, so the transformation isn't really permitted by the Standard.
That a processor which conformed to this aspect of the Standard would
be unmarketable almost goes without saying.
Which is why, once upon a time, there were those who proposed fixes
(either in more elaborate interpretations, more text in the Standard,
or new syntax which would toggle "strict" vs. "performance"
behavior). Such forces lost.
As for the specific issue which sparked this incarnation of very old
controversy, I think those that have expressed a desire for a new form
of parens would do better to work on the general problem of allowing
more user control over the optimization semantics. The parens level
really is far too small in scope, and consumes irreplaceable character
set binding ;>
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|