From: rbe@yrloc.ipsa.reuter.COM (Robert Bernecky)
Subject: Re: box vs. nest
Reply-To: rbe@yrloc.ipsa.reuter.COM (Robert Bernecky)
Organization: Snake Island Research Inc, Toronto
Date: Tue, 6 Oct 92 15:25:23 GMT

In article <921005051057_70530.1226_CHH4-3@CompuServe.COM> Mike Kent <70530.1226@CompuServe.COM> writes:
>In article <1992Sep30.231307.21354@yrloc.ipsa.reuter.COM>,
>loc@yrloc.ipsa.reuter.COM (Leigh Clayton) writes:
>
>> ... 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.  

This is baloney. I'm sure there's a better word for it.
Regardless of the religious stuff you use to describe it, the following
hold true:
a. BOTH Dictionary APL and APL2 introduce new data types into the
   interpreter. You can deny that these exist (just as some deny that
   APL doesn't have different types of numbers: Boolean, integer, float,
   complex), but they are there, and not only CAN be detected, but
   still affect applications, in spite of our best efforts to hide them
   from the user.

    Both systems represent enclosed arrays as arrays of pointers.
    APL2 is slightly more complicated than vanilla Dictionary APL
    because it REQUIRES heterogeneous arrays to be supported.
    Dictonary APL permits hets, but does not require them. 

    Dictionary APL is richer than APL2 because of them there 
    data structures. SAX permits:
      5,< 'abc'
    and
      (<5), <'abc'
    AND lets you tell them apart. APL2 treats both above expressions
    as identical to the first one. Not at all important to 99% of
    applications (none of this stuff is...), but Dictionary APL
    does permit you to embed information in the "data structure"
    in a loss-free manner. APL2 does not.

   So, the above stuff by Kent has nothing to do with reality. It
reflects a certain religious attitude which some people would like to
foist on the world as Being True. It Ain't.

Pervasion has to do with the definition of HOW a function applies to
non-simple data. Dictionary APL separates these issues into orthogonal
issues, and lets the user specify the desired behavior. APL2 forces
pervasion on the user, willy nilly. 

Dictionary APL, as I weary of telling people over and over and over again...
{sorry. I get tired of this ...}

can do any of the following, without changing ANY religious tenets:
a. GIve domain error on A+B, where one of them is non-simple.
b. Introduce a "pervasion-level" adverb, akin in spirit to the 
    "rank adverb". This would let a user specify the depth at which
   a primitive is applied. Unlike the bolted-in pervasion of APL2,
   a user could choose how things apply. For example, 
      matrixdivide&3 
   (where & denotes my just-invented pervasion adverb) would apply
   matrix divide to each array at nesting level 3. 
      f&_ would apply f at leaves - infinite depth.
c. Just as with function rank, a "default depth" for each primitive
   can be adopted. As with APL2, infinite depth can be used for
   what we called "scalar functions" in the bad old days.
   Unlike APL2, we can freely adopt _2 (or is it _1?) as the depth
   for matrix divide: Applying to each array near the sea floor.
   The pervasion adverb can then be used to alter this default behavior.
   For example, +&0 might be used to force APL\360-like domain errors.
 
So, they ARE separate issues. Please stop rolling everything into one
large, confusing theoretical lump when orthogonalization results in
simpler, more productive definitions.

>
>
>> ... 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,

The former.

Strand notation is a change to the syntax of the language. APL2 would
work perfectly fine without those changes. Better in fact, since
indexing of constants would still work.

The stuff about confusion of enclose and indexing is just that.
Smoke and mirrors. 

>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

Then how come APL2 gives  1 2 3[1] an error, when "from time immemorial",
it worked?

>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,

So, how come SAX has hets and enclose both without problems? How does
your view of the Galactic All explain reality?


>but which is not itself 5).  [Nothing new here; cribbed from various
>papers by Benkard and by Brown.]

Obviously.

Robert Bernecky      rbe@yrloc.ipsa.reuter.com  bernecky@itrchq.itrc.on.ca 
Snake Island Research Inc  (416) 368-6944   FAX: (416) 360-4694 
18 Fifth Street, Ward's Island
Toronto, Ontario M5J 2B9 
Canada
Newsgroups: comp.lang.apl