Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!linus!philabs!cmcl2!harvard!caip!princeton!allegra!ulysses!bellcore!decvax!decwrl!blickstein@dregs.dec.com
From: blickstein@dregs.dec.com
Newsgroups: net.lang.apl
Subject: Re: Nested arrays
Message-ID: <3353@decwrl.DEC.COM>
Date: Sun, 1-Jun-86 03:56:10 EDT
Article-I.D.: decwrl.3353
Posted: Sun Jun  1 03:56:10 1986
Date-Received: Tue, 3-Jun-86 22:33:10 EDT
Sender: daemon@decwrl.DEC.COM
Organization: Digital Equipment Corporation
Lines: 69


I think some of the most significant features of nested arrays have been
overlooked in the discussion here.

Most of the discussion has centered on how nested arrays give you more
flexible data representation.   The examples pretty much amount to how
you can use nested arrays in ways similar to records and structures in
the various "FORGOL" (my term for procedural languages that are descendents
on FORTRAN (Pascal, Ada, C, etc.)).  

While this kind of usage is unquestionably a tremendous benefit to APL users, I
think one of the principle motivations behind them was to be able to apply
operators and functions more flexibly. It's not very exciting to be able to
represent data more naturally unless you are also given the means to operate on
it more naturally as well. 

For example, in regular APL, operators are limited to scalar functions
(functions that operator on one (monadic) or two (dyadic) scalars to
produce a third scalar.  Why this limitation?  Well obviously without
nested arrays operator usages like 3 o. rho 4 5 6 would be undefined.
(RESULT[1] would have to be 3 rho 4 (a vector), but the shape of RESULT[1]
is by definition a scalar?)   Nested arrays give this example a meaningful
definition:  (4 4 4) (5 5 5) (6 6 6).   This is a three element vector
where each element is a nested 3 element vector.   rho RESULT[1] is '',
but rho disclose RESULT[1] is 3.

So clearly operators can now be generalized to accept practically any
function because it no longer matters that the function returns something
other than a scalar.

There's a lot you get right there, but what the most important benefit
is when you realize that it now becomes meaningful to apply operators
to USER DEFINED functions.  This removes the need for most loops in
APL.   It also allows you to write shorter AND CLEARER programs because
you can now use APL primitives where you couldn't before.  For example, if 
you write a function PAYROLL that processes one employee record (presumably in 
an array EMPLOYEES) in current APL you'd probably have to write a loop 
that makes a call to PAYROLL at each iteration i to process EMPLOYEE[I;].

That is you are applying PAYROLL to each row in EMPLOYEE, a very APL-ish
thing to do, but you have to do it in a loop.   In nested arrays this
could be done simply with each employee.  (Each is a new operator available
on most nested array implemetations that applies a function to each element
(or slice) of an array).

This is obviously a clearer program than the one with the loop because
it's a DIRECT notation for what you are doing (applying PAYROLL to each
EMPLOYEE), whereas it might take a little mental processing to figure
out the loop that does the same thing.

Because the use of operators is FAR less restricted with nested arrays,
you see a lot of new operator-related enhancements in most nested array 
implementations including:

	1) New operators like each.
	2) Derived functions.  That is "3 +" is a "derived" monadic function
           that adds 3 to its argument.  (It is often useful to compose a
           derived function to be passed as an operand to an operator.)
	3) User-defined operators (on some systems).

If I had to give a summary description of what nested arrays buys you, it
would be something like: APL works most naturally on arrays and nested arrays
allow you to treat more things directly as arrays.

	Dave Blickstein

(UUCP)  {allegra|decvax|ihnp4|ucbvax}!decwrl!dec-rhea!dec-tle!blickstein

(ARPA)  BLICKSTEIN%TLE.DEC@DECWRL.ARPA