Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!apple!usc!merlin.usc.edu!usc.edu!raulmill
From: raulmill@usc.edu (Raul Deluth Rockwell)
Newsgroups: comp.lang.apl
Subject: Re: APL Machines
Message-ID: <RAULMILL.89Sep9140300@usc.edu>
Date: 9 Sep 89 21:03:00 GMT
References: <RAULMILL.89Sep3123434@usc.edu>
        <1989Sep5.153557.9841@ziebmef.mef.org>
Sender: news@merlin.usc.edu
Distribution: comp
Organization: University of Southern California, Los Angeles, CA
Lines: 58
In-reply-to: raulmill@usc.edu's message of 9 Sep 89 20:54:43 GMT

In article <1989Sep5.153557.9841@ziebmef.mef.org> daniel@ziebmef.mef.org (Daniel Albano) writes:

   There was an APL machine (by that name) produced by a corporation
   somewhere on the east coast of the US.  It was based on 68000 
   processors ...

I suppose I wasn't very explicit on this point.  By APL machine, I
meant a machine who's CPU architecture was oriented towards APL data
structures and operations.  I didn't mean to imply that I was talking
about machines which 'merely' run APL.

Also, note that there is no need for APL to be the only language that
runs on the machine.  The important point is that the machine
architecture is an optimal one for APL.

   As for performance, type checking and rank checking should not be a
   major concern ... (... if the data pointed to by the symbols are a
   decent size).

That is exactly the point.  If your algorithm must use small data
structures with any frequency, you lose.  I do not think that you can
make the assumption that small data structures are unimportant.

   I suspect that there is no advantage in embedding APL arrays in an
   internal vector representation.  ... if the data are really
   3-arrays, why not store them as such (which are really vectors
   anyway, but why confuse ourselves! :-) ).

Now I'm confused 8*).

Seriously, the advantage of vectors over arrays is that they require
less complexity in the machine that implements them. I don't think
that I could design a generalized array language that didn't HEAVILY
rely on the structure of a vector.  Wouldn't you gain something by
considering this in a design?

   If it is to be a real APL, I don't think you can omit []CT and
   []IO ...

Not in the interpreter, sure.  But that doesn't mean that you couldn't
implement the interpreter in an APL-like language which doesn't have
these.  For example, you could implement = as:

_
V RESULT <- LEFT EQUAL RIGHT 
                  __                                      _
  RESULT <- (LEFT |  RIGHT) < (LEFT | RIGHT) x 1 + QUADCT V
                                    L

Just in case:
_                         __
V del    <- assignment    |  ceiling    x times    | floor
                                                   L

I appreciate the comments, but this is getting a bit off of the track
of the original article.  Can I redirect the track onto the idea of an
efficient implementation of APL in terms of machine hardware?
--