Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!iuvax!pur-ee!hankd
From: hankd@pur-ee.UUCP (Hank Dietz)
Newsgroups: comp.lang.fortran
Subject: Re: dpANS Fortran 8x
Summary: Naming Fortran-like languages by number: 66, 77, and 8x
Message-ID: <11943@pur-ee.UUCP>
Date: 14 Jun 89 23:55:17 GMT
References: <2716@elxsi.UUCP> <13934@lanl.gov> <135@unmvax.unm.edu> <11935@pur-ee.UUCP> <145@unmvax.unm.edu>
Reply-To: hankd@pur-ee.UUCP (Hank Dietz)
Distribution: usa
Organization: Purdue University Engineering Computer Network
Lines: 61

In article <145@unmvax.unm.edu> brainerd@unmvax.unm.edu (Walt Brainerd) writes:
>In article <11935@pur-ee.UUCP>, hankd@pur-ee.UUCP (Hank Dietz) writes:
>> More to the point, it isn't recognizable as Fortran.
>> ... 
>> I started with ANSI66 and, quite honestly, I still do a doubletake
>> when I see ELSE in "Fortran" code.
>> ...
>> So, I'm opposed to pointers in Fortran on the basis that pointers are *very*
>> alien to the existing Fortran idioms.  Translation:  if you want pointers,
>> use C or some other language where that construct is understood by most
>> programmers -- it is part of anyone's idiom.
>
>I don't understand.  You say it is alien to Fortran, but it is part of anyone's
>idiom.  So if you are capable of making the switch to C, why are you startled
>by the radical new ELSE statement and the possible introduction of pointers?

I'm not surprised to find a steering wheel in a car, but I'd be a bit
startled to find one on a motorcycle.  Wouldn't you be?  I'd be even more
upset to find both handlebars and a steering wheel.

The example of ELSE in ANSI77 is admittedly extreme, but I am quite serious
about it not being part of my Fortran idiom....  I was involved in the ACM
Programming Contests back when they required use of pure ANSI66, hence, I
learned to use a pure ANSI66 Fortran idiom.  Also, ANSI77 conforming
compilers used to be hard to find, hence careful ANSI66 code was *much* more
portable.

Incidentally, even then my "native" language was C.  Old C, not the *mildly*
incompatible thing becoming known as ANSI C....  I like the new function
prototypes, etc., but I'm not thrilled about ANSI C being incompatible with
old C and still being called C.  Get the point?  There should be one and
only one standard for each language...  the new (upgraded?) languages ought
to be given new names.  Truth in advertising and all that.

>Switching to C is a perfectly reasonable thing to do in some circumstances,
>but a great many Fortran programmers to not have that option,
>and they have jobs to get done for which pointers, recursion, data structures,
>and all kinds of new 1970s type software innovations are very helpful.

My point is that suddenly redefining "Fortran" to be a language which
supports "pointers, recursion, [and] data structures" is really defining a
completely new language (i.e., set of idioms).  An Fortran (ANSI77) wizzard
isn't necessarily going to understand what those pointer thingies are doing
in some new Fortran program he's handed...  does that mean he's no longer a
Fortran wizzard?  Even ANSI77 was significantly different from ANSI66, but
the new "Fortran" will be *very* different.  It will be "Fortran" in name
only (even lexically different!).

If you want a more modern language which maintains some of the structure of
Fortran, *add* the new constructs and *remove* the old ones supporting
outdated idioms (e.g., comparatives like .GT., arithmetic IFs, etc.) and
then come up with a new name for it.  Heck, add classes and call it F++ (or
would that be D-?) ;-).  If you care about old Fortran code, supply an
ANSI77 to F++ conversion program with the F++ standard.  Just don't tell me
it is "standard Fortran."

						-hankd@ee.ecn.purdue.edu

PS: Usually, I don't flame like this, but *somebody* had to say this stuff.
PPS: Notice that people talk about 66, 77, and 8x rather than Fortran;  I
 suppose calling Fortran-like languages by numeric names makes sense. ;-)