Newsgroups: comp.lang.apl
Path: watmath!watserv2.uwaterloo.ca!watserv1!70530.1226@compuserve.com
From: Mike Kent <70530.1226@CompuServe.COM>
Subject: box vs. nest
Message-ID: <921005051057_70530.1226_CHH4-3@CompuServe.COM>
Sender: root@watserv1.uwaterloo.ca
Organization: University of Waterloo
Date: Mon, 5 Oct 1992 05:10:58 GMT

In article <1992Sep30.231307.21354@yrloc.ipsa.reuter.COM>,
loc@yrloc.ipsa.reuter.COM (Leigh Clayton) writes:

> ...the STSC/NARS definition (adopted by APL2) ...

Bad history.

Newton didn't copy Leibniz, and Brown didn't copy Smith:  the STSC and
IBM developments of generalized arrays were independent efforts.  Bob
Smith's NARS system was inspired by the discussions which was going on in
the late 70's, initiated *particularly* Jim Brown's Ph.D. thesis; of
course, Jim's work at IBM was based on the same ideas.  While STSC did
indeed have the first commercially-available generalized arrays
implementation in 1981 (not NARS, they warned customers that NARS was the
Nested Arrays *Research* System, and they shouldn't put production work
up on that system), IBM had internal-use versions of APL2 earlier.  IBM's
commercial release was in 82 or 83 but they had been letting customers at
the IUP for a while before that.

> ... the pervasion of functions into the depths of APL2 arrays has
> absolutely nothing to do with the definition of enclose ...

Not so.  The Dictionary enclose produces a result which is of a different
*datatype* from its argument (and all <'d arrays are of the same data
type).  APL2 enclose produces additional data structures, but does *not*
produce new types.  Thus -(1 2)(4 5) is (as required by scalar extension)
(-1 2))(-4 5), while (because <'d arrays are not of numeric type (but 
instead of boxed type))   -(<1 2),<4 5    is a DOMAIN ERROR.  That's
a real and significant difference.  The pervasiveness of scalar functions
in APL2 is a consequence of two design decisions:  scalar extension
continues to apply to nested arrays; nesting does not produce new data
types.  


> ... strand notation ... has nothing to do with the choice of enclose 
> axiom system ...

Either I completely misunderstand what you're saying, or you're just 
dead wrong.  Once you allow strands, say  (V V) where V is some vector,
you have to allow (V V)[1].  And the shape rules for indexing say that 
(V V)[1] is a scalar, since 1 is a scalar.  APL2 says that enclose is the
function which produces (V V)[1] upon monadic application to V.  Now from
time immemorial (or at least since commas weren't required in
representations of numeric vectors), (5 5)[1] has returned the simple
scalar 5.  So the enclose of that simple scalar must be ... the same
simple scalar.  That's just congruence closure, which you surely want:
if F and G are the same function, and A and B are the same data, then
F A and G B are the same value also.  So strands imply that a function
with the behavior of the APL2 enclose CAN be defined (though they do not
of course require that it must be a primitive).  But strands do not imply
the existence of a box-like function (or else it would possible to
produce within APL2 a scalar entity which discloses to [the scalar] 5,
but which is not itself 5).  [Nothing new here; cribbed from various
papers by Benkard and by Brown.]

// mike   ... let's see; a little gasoline should douse these flames ...


