brainerd@unmvax.unm.edu (Walt Brainerd) (08/31/89)
Some more interesting stuff sent to X3J3 regarding array processing
(by Andrew Mullhaupt):
==================================================================
Perhaps I can clarify my opinion: I think looking like APL is not a
good thing. I don't like the overly terse APL language as a whole,
but I really enjoy the functionality. I often write cover functions
for APL idioms so that they are 'human readable'. There is no reason
(that I can see) preventing FORTRAN syntax from supporting appropriately
named scan, reduction, and outer product semantics, but I'm not an expert.
The main difficulty would seem to be that reduction needs to be passed
an operation, to be perfectly general. Why not restrict reduction to
user supplied functions of two arguments. The user can write the easy enough
function ADD(X,Y) that adds two scalars if he wants the + reduce of an
array. In this way reduction (and other APL 'operators') can be FORTRAN
'functions' which have functions as arguments in the usual FORTRAN way.
The advantage of having reduction as a language extension is that the
scalar extension (which MS FORTRAN 5.0 has) applied to the user supplied
function would not necessitate having a different REDUCE function for
each different choice of argument types. A considerable advantage, in my
opinion. I would use non-standard FORTRAN supporting these features, and
I am normally very standard-oriented.
Andrew Mullhaupt
And while I'm at it...
Adding a good set of APL array moves to FORTRAN would have two important
side effects:
1. They would undoubtably run very fast compared to APL, which would have
an effect on the way APL implementers think about efficiency. (They might
start thinking about it).
2. A uniformly high level set of powerful primitives allows machine designers
and compiler implementers to take advantage of parallelism and vectorized
hardware in a source-portable way. A lot of people who want the advantage
of parallel hardware without the prohibitive cost of special code development
would be glad of this aspect.
Lord knows I would much rather that Pascal or Modula-2 be the language with
the spiffy new array stuff, but this is traditionally the area where FORTRAN
has lead the way in the past; big fast number crunching add-ons. It may
be enough to keep me interested in FORTRAN for another ten years.
Andrew Mullhaupt
--
Walt Brainerd Unicomp, Inc. brainerd@unmvax.cs.unm.edu
2002 Quail Run Dr. NE
Albuquerque, NM 87122
505/275-0800