otto (11/30/82)
This is just a note to let people know that I am about to release in this
newsgroup my detailed reactions to using the APL/11 program available from
Purdue for PDP-11's and VAXen. This soon-to-come analysis will include a
listing of the log I have been keeping while using this APL program.
However, I thought it would be useful to present my general reaction to this
program now even in the absence of detailed support. Therefore, ...
I am pleased to have in APL/11 an implementaion of APL that works reasonably
well. I have an APL terminal, and it is quite nice to get into the program
from UNIX(tm), flip it into APL mode, and use the program as a powerful desk
calculator. The typical, middle-of-the-road kind of things that one usually
wants to do with APL primitives work correctly in this use, and there is
quite a lot of power at ones fingertips with this program.
However, this APL is non-standard in many ways -- ways that become important
when function definition is employed. At such a time more precise,
complete, and exacting use of the language is required. I have found that
APL/11 misbehaves under many boundary conditions which become evident when
workspaces are being defined with collections of functions.
A typical example is the following: a useful idiom in APL for telling if an
array A is character or numeric is
' ' = 1 take 0 take ,A
It returns 1 if 'A' is a character array, and 0 otherwise. Unfortunately,
this idiom fails in APL/11 in two ways. First, a '1 take' from a null
vector in APL/11 does *not* produce a vector of zeros or blanks, as expected
(depending on the type of the null vector). Instead, it erroneously produces
floating point numbers or non-printing characters. Secondly, there is a
non-standard restriction in APL/11 that makes
' ' = 0
an illegal expression. Thus the first expression fails -- producing an
error message -- if 'A' is numeric. The test can be reformed into APL/11 as
' ' = -1 take format -1 take 2 take 1 take ,A
where all the '-' signs represent overbar characters. However, this is
clearly more complicated than it needs to be. It is also rather frustrating
to have to work around such non-standard difficulties because of
implementation constraints.
I have found numerous similar instances, which can best be described as
*boundary condition failures*, where primitives fail in the presence of null
vectors or multidimensional arrays but work correctly when the arguments are
garden-variety vectors. I will present more detail about all this in my
forthcoming report to this group.
George Otto
Bell Labs, Indian Hill
----------------------ecn-pa:bruner (12/01/82)
Unfortunately, APL\11 is a very old program (I believe it predates
V6 UNIX) and some of the problems that George Otto has mentioned
(and will mention) are very difficult to fix. I don't remember
exactly why doing a "take" on a null vector is incorrect; at one
time you couldn't take more than the array contained (for instance
5 take 3 rho 0
was not accepted). I checked the code and my private log of changes
and I mentioned at the time that taking from a null didn't work.
I haven't worked on it in quite a while; it was always a peripheral
project and my thesis deadline is now 10 days away.
Anyway, the principal point of this news submission is to tell anyone
who may be interested in APL\11 that I won't be here to distribute
it anymore. If you'd like a copy you should contact my former
major professor, Dr. Anthony P. Reeves, who is now at Cornell. You
can reach him at "{decvax,harpo}!cornell!reeves".
--John Brunerjohnl (12/03/82)
Here's the true scoop on so-called APL/11. It was originally
whipped up by Ken Thompson in about two days, and I later got it, fiddled
for a week or so, and sent it out to Usenix. It was on the first or
second Usenix tape, a long time ago. Since then it's bounced around a
certain amount and appeared (with some wrong guesses about its origin) in
4BSD. To make it full APL, a lot of work would be needed. Last time I
checked, its weaknesses included:
No terminal independence
No labels in functions
Kludgy function compilation which causes flakes when function
definitions change
No function editor
No state indicator
No file package
No shared variables
Teensy-weensy workspace (better on the vax than the 11, though)
Dubious behavior with arguments in limiting cases (e.g. null args)
The expression evaluator is nice, so it's OK as a desk calculator but a
decided loser beyond that. I haven't touched or looked at it in years,
so please don't ask me for fixes.
John Levine, IECC, PO Box 349, Cambridge MA 02238; (617) 491-5451
decvax!yale-co!jrl, harpo!esquire!ima!johnl, ucbvax!cbosgd!ima!johnl (uucp)
Levine@YALE (Arpa).