Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!uunet!portal!cup.portal.com!Pesch
From: Pesch@cup.portal.com (Roland Henry Pesch)
Newsgroups: comp.lang.apl
Subject: Re: APL Machines
Message-ID: <22186@cup.portal.com>
Date: 15 Sep 89 21:32:58 GMT
References: <153557@<1989Sep5> <49700014@uicsrd.csrd.uiuc.edu>
Organization: The Portal System (TM)
Lines: 67


[most of excellent articlel by Greg Jaxon omitted]

>> "Dictionary APL"  NOT the "APL2" dialect.
>
>Firstly I'd urge any APL designer to become deeply familiar with BOTH these
>language definitions, and to really use BOTH systems.  The dictionary approach
>("function rank") is really a wonderful perfection of the original APL array
>processing ideas.  I suspect it is more efficient to implement, because it is
>a little less powerful than the equivalent features in APL2.  In "Dictionary"
>APL, operators are much more powerful.  If operators can really manipulate
>the functions (e.g. pipelining them, carrying temporary results in registers,
>etc.)  then I'd say the dictionary approach is best suited to today's 
>vector supercomputers.   
>
>But "function rank" seems tied to homogeneous arrays (am I wrong here?)

Wrong (just that last sentence, not the most insightful paragraph I couldn't 
resist quoting first), but not surprisingly: Ken Iverson took a long time 
to add heterogeneous arrays to the Dictionary.  The version published in 
Quote Quad includes them, I think, though with little fanfare.

Moreover, we've included them in SAX (an APL interpreter and associated
programs for the Unix environment, produced by I.P. Sharp Palo Alto in
collaboration with STSC), which is to my knowledge the most complete implemente
d
subset of Dictionary APL.  (Unfortunately it's also kind of hard to get---
we try to concentrate on OEM sales, for overhead reasons).  But there's
nothing in Dictionary APL which conflicts with mixed arrays; they're just
not essential, as they are in APL2 (in Dictionary APL, it's largely a matter
of extending the domain of a few primitives like catenate ---formally, that
is, internally naturally there's a fair bit of work--- but in APL2 they're
a degenerate case of the enclosed universe, so they're essential).
 
>There are real limits on programmers' ability to forsee what a function
>expression will do.  In the APL2 approach, all the data decompositions are
>explicitly written out, you can enter the subexpressions and watch what's
>happening to your data.  You can also do all kinds of unorthodox decomposition
s
>of your data, which stand no chance of being vectorizable.

I'm not entirely sure whether that paragraph is supposed to be part of
the text contrasting Dictionary APL and APL2.  If so, I should point out
that although the statement is quite true, Dictionary APL does include
the "box" and "open" primitives (similar to enclose and disclose).  We find
that it's frequently easier to write an algorithm usingn them in the first
place, while you're groping around trying to understand it; then later,
when you know what you're doing, it's often possible to dispense with box and
open and do something elegant with operators and flat arrays, instead.

[much more great stuff omitted]

>Thanks in advance for any replies!
>
>greg jaxon -- jaxon@uicsrd.csrd.uiuc.edu
>Univ. of Ill. Center for Supercomputing R&D

You're most welcome---and it's very good to hear from you!  I'd lost track
of where you were...

                              /Roland Pesch
                               pesch@pa.reuter.com  (or: pesch@cup.portal.com)

                               SAX Development Group
                               I.P. Sharp Associates
                               425 Sherman Ave., Suite 200
                               Palo Alto, CA   94306