Newsgroups: comp.lang.fortran
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!magnus.acs.ohio-state.edu!csn!convex!newsadm
From: Patrick F. McGehearty <patrick@convex.COM>
Subject: Re: Fortran standardization process (was: Fortran 90 status)
Message-ID: <1991Apr29.150953.12878@convex.com>
Sender: newsadm@convex.com (news access account)
Nntp-Posting-Host: mozart.convex.com
Reply-To: patrick@convex.COM (Patrick F. McGehearty)
Organization: Convex Computer Corporation, Richardson, Tx.
References: <1991Apr26.210247.17264@ariel.unm.edu> <1266@argosy.UUCP> <1991Apr29.034625.25562@ariel.unm.edu>
Date: Mon, 29 Apr 1991 15:09:53 GMT
Lines: 53

In article <1991Apr29.034625.25562@ariel.unm.edu> prentice@triton.unm.edu (John Prentice) writes:
...  What I am 
>criticizing is a standards process so slow that it is twenty years
>between implementations of modernized versions of the language.  In an era 
>when hardware developments are producing an order of magnitude increase 
>in performance every few years, my point is that the current
>process of producing a standard is an anarchism.  If Fortran fails to rapidly 
>evolve features which support things like parallelism, it will be
>rapidly replaced by languages that do, at least amongst scientific
>users who are pushing the frontiers of computing.   The same is true
>of C or any other language subject to standarization.  But C is a 
>language that has a following across a broad segment of the computing
>community and in particular to segments of the community that are not
>that heavily involved with or in need of extraordinary floating point
>performance.  There the basic paradigm of computing is not changing
>rapidly, it is still overwhelmingly based on serial computers.
>On the other hand, Fortran has a rather narrow following limited mostly 
>to those people who are doing very high performance floating point computing
>where the paradigm of computing is rapidly evolving from serial to
>parallel computing.  If Fortran fails to provide the software tools needed by
>that switch, then it will get abondoned by the high performance scientific
>computing community simply out of necessity.  And that will leave the language
>in a backwater.  It will continue to be used by scientists less concerned
>about state of the art performance for awhile.  But eventually even these
>people will move on to parallel systems as they become more commonplace and
>hence away from Fortran. The real lifeblood of the Fortran community has been 
>and is today the high performance scientific community.  Failure to address 
>the needs of that community will doom this language.
>
I agree in general with the ideas expressed above.  I am somewhat more
optimistic about the prognosis.  I make a distinction between formal
standardization and usable common practice.  Various extensions are
common to Fortran, and most serious vendors support them, even though
they are not part of the FORTRAN77 standard (DO ... ENDDO is an example).

In a similar way, various parallel constructs have been added to different
vendors Fortran implementations.  For example, Convex uses a "C$DIR ..."
syntax for Convex specific extensions.  Other vendors use other syntaxes.
While these divergent practices inhibit portability in the short term,
they allow a body of experience to be developed.  Those features which
are found to be useful are likely to be included in interim standards,
such as that due from the Parallel Computing Forum (PCF).  Since these changes
are much less extensive than FORTRAN 90, they are likely to be widely
available within a couple of years of a standard, instead of decades.
Of course, each vendor will have their own timetable, which will be
driven in part by their customer requirements.

I encourage all those reading this who are interested in high performance
computing to get a copy of the PCF interim/draft/(whatever it to be called)
standard when it emerges and read it carefully.  Please evaluate the
standard for your needs.  I know that I will.  Only ask for features that
are meaningful and consistent, otherwise standardization and implementation
times will be extended.
