On Thu, 2013-11-28 at 09:41 +1300, John Harper wrote:
> At present some compilers deal with the statement
> x = merge(tsource,fsource,mask)
> by first evaluating mask and then whichever of tsource and fsource is
> needed, while others evaluate all three arguments of merge. That makes
> merge less useful than it would otherwise be, because evaluating
> the "wrong" one of tsource and fsource might trigger an exception.
> Is there any chance that a future standard might require tsource to
> be evaluated if and only if mask is true, and fsource to be evaluated
> if and only if mask is false?
This problem was observed during development of Fortran 90.
Requiring (as opposed to allowing) lazy evaluation, even only in the
case of a scalar MASK, appears to be anathema to Fortran committee
members.
Conditional expressions were proposed in
http://j3-fortran.org/doc/year/13/13-234.txt for the work plan for
Fortran 2015 (and similarly for 2003 and 2008), but the ISO and ANSI
committees decided to sit on their hands again, as happened between 1966
and 1990, thereby allowing C and Pascal to take the lead. This prompted
Edsgar Dijkstra to write "Fortran, 'the infantile disorder,' by now
nearly 20 years old, is hopelessly inadequate for whatever computer
application you have in mind today; it is too clumsy, too risky, and too
expensive to use." Some of us have been fighting, and unfortunately
largely losing, an uphill battle to rectify the problems that prompted
Dijkstra to write this.
Part of the problem is that the US ANSI committee, to which the ISO
committee has delegated development responsibility, has dwindled to
seven members, of whom only two represent Fortran users. I don't know
for sure that this is what vendors want, but it appears that their
primary objectives are to limit their work load, and seek anti-trust
protection.
Similarly, the ISO committee has dwindled to five delegations (US, UK,
Germany, Netherlands, Japan).
To achieve more than a feeble token modernization, the committees need
more members, especially representing Fortran users, to show up and do
the work. It's nice to say "Please do this thing that would make users'
lives easier," but somebody has to write the words, and verify that they
don't introduce an inconsistency with the existing standard or other
newly to-be-introduced features.
The trivial 2015 work plan is attached. The part entitled "Not to be
pursued" lists items proposed to the ISO committee by UK and US
delegations, but cut from the plan at the last minute. The US
delegation, and perhaps the UK delegation as well, pondered much longer
lists, but delegations were told to submit short ones.
J3 papers (13-*) referenced in the attachment are available from
http://j3-fortran.org/doc/year/13. WG5 papers (N*) are available from
ftp://ftp.nag.co.uk/sc22wg5.
> -- John Harper, School of Mathematics Statistics and Operations Research
> Victoria University, PO Box 600, Wellington 6140, New Zealand
> e-mail [log in to unmask] phone (+64)(4)463 5276 fax (+64)(4)463 5045
|