Path: utzoo!mnetor!uunet!husc6!cmcl2!beta!a!jlg
From: jlg@a.UUCP (Jim Giles)
Newsgroups: comp.lang.fortran
Subject: Re: Fortran 8x, recursive procedures
Message-ID: <535@a.UUCP>
Date: 25 Mar 88 02:24:41 GMT
References: <522@a.UUCP> <1180@hubcap.UUCP> <4737@aw.sei.cmu.edu>
Distribution: na
Organization: Los Alamos Natl Lab, Los Alamos, N.M.
Lines: 29
Summary: Extensions to Fortran

In article <4737@aw.sei.cmu.edu>, firth@sei.cmu.edu (Robert Firth) writes:

> Also, I'm a bit puzzled by the idea of "extending Fortran for hypercubes".
> Extending Fortran for, say, business data processing sounds like a good
> idea, since that's a genuine problem domain.

"Extending Fortran for hypercubes" obviously means that they are extending
the language to better utilize hardware features inherent to the target
machine (for hypercubes this probably means recursion and variable sharing
in a multi-tasking environment).  This is a perfectly normal thing to do 
to Fortran and has been common practice for researchers and hardware vendors
for years - extend Fortran to meet the characteristics of the machine.
Such extensions are usually modest: New data types (remember REAL*4 and 
REAL*8?); New intrinsic functions; and, most recently, super-computer
vendors adding vector syntax.


Extending Fortran for business data processing doesn't sound like a good
idea to me.  There are already other languages that are better suited to 
that area.  Fortran is best suited to scientific number-crunching - let's
keep our extensions targeted to that set of problems.  (This is not to say 
that there may not be overlaps in the features of languages.  If Fortran
users would benefit from some feature that also has uses in business data
processing, I see no reason not to include it.  But, Fortran should not seek
to widen its scope to types of problems that are best solved with other
languages.)

J. Giles
Los Alamos