From: rbe@yrloc.ipsa.reuter.COM (Robert Bernecky)
Subject: Re: Sharp APL
Reply-To: rbe@yrloc.ipsa.reuter.COM (Robert Bernecky)
Organization: Snake Island Research Inc, Toronto
Date: Thu, 1 Oct 92 04:36:35 GMT

In article <1992Sep29.192450.3393@magnus.acs.ohio-state.edu> pviton@magnus.acs.ohio-state.edu (P A Viton) writes:
>
>Does anyone know of a discussion in which  Sharp's implementation of
>nested arrays (called "boxed" arrays, I think) is compared to
>the implementations of IBM (APL2) or STSC (APL*PLUS II)?

Good topic for religious jihad, this. 

Thumbnail sketch:

Both systems take ANY argument array and produce a scalar result
from the "enclose" or "box" functions. Both systems have "disclose"
or "open" functions which, given the result of enclose/box, produce
the original array. 

For 99% of applications, the above works fine, and there's no big
deal difference from one to the other.

A niggling difference is that given a SIMPLE SCALAR (such as a
single character or number), APL2/STSC enclose is nilpotent. That
is, enclose 'x' is 'x'. However, enclose 'xx' is NOT 'xx' (enclose/box
always returns a scalar), AND enclose enclose 'xx' is NOT the same
as enclose 'xx'.

SHARP APL and SAX, VOS3 APL (Hitachi), Fujitsu APL, Siemens and Philips APL
systems, all make box produce a scalar which ALWAYS differs from the
argument.

The difference in implementations is that APL2/STSC FORCE a system to
support heterogeneous arrays, whereas SHARP APL permits it, but doesn't
require it. Also, SHARP APL permits you to encode information in the
depth of an array (how many times you applied box to it), whereas
APL2 loses information here. 

Another way to view it is in set theory: SHARP APL contains all the
arrays in APL2, as well as as infinite set of arrays which are NOT
in APL2: The set of scalars boxed to an arbitrary depth.

That sums up the differences between the systems as far as enclose/box
is concerned. 

Now,

\begin{tirade}
APL2 has decided that The Wave Of The Future is enclosed arrays, and
extended MANY operators/adverbs in a way that both limits the 
extensions of non-enclosed arrays, and forces the introduction of
enclosed arrays in places where they are in fact undesirable.

For example, reduction on a matrix is not defined! Reduction on a 
vector is allowed, and defined in terms of a dual with disclose 
composed with the reduction verb. If you want to apply the verb
to a non-vector argument, you have to dink around with the data,
rather than the operator expression. This results in convoluted code,
as well as (in an interpreter) more data sloshing (read this as:
slower applications) than you'd have otherwise.

Reductions on higher rank arrays than vector is performed by 
laminating the results from reduction on vectors.

In SHARP APL, reduction consists of merely slicing the array along
the leading axis, sticking the reduction verb between the resulting
subarrays, and evaluating THAT "expression". Simple, and easy to
teach and use.

\end{tirade}


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