Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!uflorida!gatech!psuvax1!psuvm!cunyvm!byuvax!hallidayd
From: hallidayd@yvax.byu.edu
Newsgroups: comp.lang.fortran
Subject: Re: Two Fortran Standards
Message-ID: <785hallidayd@yvax.byu.edu>
Date: 5 Sep 89 08:56:38 GMT
Lines: 82

Hank Dietz (hankd@pur-ee.UUCP) in message (<12687@pur-ee.UUCP>) comments

>>F77 is being retained as a subset of F8x; this provides both the
>>protection and the progress.
>
>Did I miss someone talking about a Fortran subset standard?  I'd be perfectly
>happy if they kept Fortran 77 active as the subset dialect standard.  ;-)

What do you mean by the smiley?  I don't care if FORTRAN 77 is called a subset
dialect standard or not (it is not presently called such), however, what some
people do not seem to be getting though there thick heads is that FORTRAN 77
is retained as a proper subset of Fortran 8x (meaning that ALL FORTRAN 77 code
will run under Fortran 8x)!  Why must FORTRAN 77 also be graced with the status
of a subset dialect (or, as appears the case now, a separate standard)?!?  Why
is it not enough to retain _FULL_ backward compatibility with FORTRAN 77 (even
with the archaic parts of that archaic language)?

>
>I've talked to many folk about the standard, and the comments fall into four
>catagories:
>
>[1]        No comment (usually, "I'm afraid to do anything because I don't want
>        to risk offending any of our customers").
>
>[2]        I hate the 8x standard and will not use it (usually, "I've always
>        used 66/77, and I'm not gonna rewrite the code nor retrain the
>        programmers" but also folks like me saying "it clearly is a
>        different language and to call it Fortran is dishonest").
>
>[3]        I like the standard because I believe it will finally kill Fortran.
>        (Usually, "I want to see us using Ada/Modula2/C++ and all Fortran
                                                               ^^^
>        used to have going for it was that it was consistently implemented
>        *EVERYWHERE*.)

This is _almost_ certainly true of OLD FORTRAN (it has also usually been the
fastest numeric language on most machines of interest---in other words, not
counting PCs)!  What people like myself are wanting (shall I say dying for?) is
a language that can fulfill diverse needs within a mathematical (though not
always numeric) framework, with high efficiency. Old FORTRAN fulfilled the
narrow needs of some who required only elemental mathematical operations with
the possibility of grouping data into arrays.  The trouble is that the needs of
the scientific computing community (by no means the only group to use FORTRAN,
but the group most often cited as the principle users of FORTRAN) have outgrown
FORTRAN (even as advanced as VAX FORTRAN) --- we need much more!  The concept of
FORmula TRANslation, however, is something we most certainly wish to
maintain---we like the ability to have our programs look as much like the
mathematics of the problems from which they sprung as possible! (Though it is
true that Fortran 8x will help significantly with this need with its operator
overloading and defining capabilities, routine overloading, and array
operations, it really falls far short of being truly Formula translation.  I
hope Fortran 9x will be much closer.  I know I will be there fighting to see
that it does, if possible.)

>
>[4]        I like the standard because we really needed the array extensions,
>        although some of that other stuff....  (Heard only from X3J3 members
>        in favor of 8x....)

See my comments above --- I am not a member of any of the standards committees.
For the kind of computing done by the scientific community, the array operations
are certainly needed, however, this is by no means all that is needed.  The need
has long existed for recursive data types to accommodate the needs of newer,
faster algorithms (such as many body algorithms that grow as N*log(N), or even
as good as N, rather than the old N^2 that only needed matrices --- though it is
still the fastest algorithm for sufficiently small N on array processing
machines).  **Please** don't continue to force us to use a hodgepodge of
programming languages that cannot be guaranteed any semblance of the portability
that has been one of the strengths of Fortran.

>
>Most people seem to be [1] or [2].  Have others gotten similar feedback?
>
>                                                        -hankd@ecn.purdue.edu

   _____________________________________________________________________
  / David Halliday                                                      \
  |                                                                     |
  | Internet:    hallidayd@yvax.byu.edu  or  hallidayd@acoust.byu.edu   |
  | BITNET:      hallidayd@byuvax  or  hallidayd%acoust.byu.edu@utahcca |
  | Us Mail:     BYU Physics Department                                 |
  |              296 ESC                                                |
  |              Provo, UT  84602                                       |
  \_____________________________________________________________________/