Obscure APL Interpreters
Ibeam2000
and so. Some of us, in our earlier years, may have used VSAPL or
APL.SV, or any of the other well-known
But how about APL for the DEC machines, HP, APLUM, the APL from CDC
before APLUM, Burroughs, Xerox Sigma, and others?
And how about things like Vanguard APL for the Z80?
I would be interested in any comments, notes, interesting tidbits, an
so on, about some of these not-so-well-known APL interpreters.
jk
"Ibeam2000" <Ibea...@gmail.com> wrote in message
news:1167745602.8...@42g2000cwt.googlegroups.com...
[...]
>
> But how about APL for the DEC machines, HP, APLUM, the APL from CDC
> before APLUM, Burroughs, Xerox Sigma, and others?
>
> And how about things like Vanguard APL for the Z80?
>
> I would be interested in any comments, notes, interesting tidbits, an
> so on, about some of these not-so-well-known APL interpreters.
>
I wouldn't consider DEC APL "obscure"; one of the better porducts in
the industry. I've been using their VAX-11 APL for about 10 years. No
complaints - maybe a bit slow. I found it an excellent product with
excellent manuals. Large systems in DEC APL have also been built
by Mobil Oil R&D.
Karl Puder lately did the development with Digital Eq. maybe you can
google him up. One of his ideas was to make variables, assigned within
a function, "local" by default.
(Some other vendor might have implemented this feature by now).
A bit less known is Harris APL - the fastest on earth.
There's quite some information in a hardcover proceedings by STSC
(mid 80ies), maybe Ed Shaw (Renaissance) still has a copy.
jk
tel...@gmail.com
Ibeam2000 wrote:
>
> I would be interested in any comments, notes, interesting tidbits, an
> so on, about some of these not-so-well-known APL interpreters.
One of the first microprocessor APL's that was not built-into a
machine, was Erik Mueller's EMPL - APL for the 8080. I have a copy of
EMPL somewhere that loaded on an early Radio Shack TRS-80, using an
audio cassette tape. The site claims that one can still run the EMPL
interpreter, using an 8080 simulator.
http://www.signiform.com/erik/programs/empl/empl.htm
Erik later wrote the Softronics APL interpreter.
The references on Erik's site also point to other obscure APL
interpreters:
Williams, Gregg (1981, April). Three versions of APL. BYTE, 6(4),
188-208. (An evaluation of Softronics APL, APL80 by Phelps Gates, and
Vanguard APL.)
Skip Cave
elliscave.com
phil chastney
> We all know and possibly used APL2000's products, or Dyalog, IBM APL2,
> and so. Some of us, in our earlier years, may have used VSAPL or
> APL.SV, or any of the other well-known
>
> But how about APL for the DEC machines, HP, APLUM, the APL from CDC
> before APLUM, Burroughs, Xerox Sigma, and others?
well, you live and learn -- I didn't know there was a CDC interpreter
before APLUM
I used to work on a CDC 6600, and APLUM was available on that -- no
special characters (hell, remote access was a major technological
achievement, and not something you wasted on single-user terminals),
and my recollection of APLUM is that it was rather unstable, to the
point of being unusable
in fairness to the U of Maryland, the instability may have been the
result of local policies and priorities
periodically, we had to demo this thing to research people recently
returned from Canada, to prove that (a) we did have APL, and (b) they
didn't want to use it
Seymour Cray gave us a talk about future trends in hardware, &c, where
he mentioned "vectorisation", and pointed out that it was silly taking a
problem statement expressed in linear algebra, scalarising the thing so
it was expressable in Fortran, and then stuffing that code through a
vectoriser to spot the loops, in order to optimise them out -- and so
they (CDC) were looking at this thing called APL, as a more direct way
of working
whatever happened to that initiative, I wonder? . . . /phil
phil chastney
> We all know and possibly used APL2000's products, or Dyalog, IBM APL2,
> and so. Some of us, in our earlier years, may have used VSAPL or
> APL.SV, or any of the other well-known
>
> But how about APL for the DEC machines, HP, APLUM, the APL from CDC
> before APLUM, Burroughs, Xerox Sigma, and others?
>
> And how about things like Vanguard APL for the Z80?
fitting an APL interpreter onto a Z80 system was a major achievement,
and the guys involved were certainly enthusiastic -- at one point, they
had young ladies roller-skating through the City of London, dishing out
advertising material
there was a suggestion that Vanguard on a local Z80 would make a
suitable terminal setup for time-sharing users, and could also perform
some of the processing then being done on a mainframe on another
continent -- I was not part of the inner circle charged with
investigating this, but I do recall complaints that the Vanguard people
were reluctant to share the information that might such a hook-up
possible -- one of the company's founders said he was principally
interested in "getting rich", but ended up with 100% of nothing
does anybody know anybody who actually used a Vanguard system? /phil
hotair
"phil chastney" <phil.ha...@amadeus-info.munged.freeserve.co.uk> wrote
in message news:f4ymh.230005$0t1....@fe04.news.easynews.com...
NoSpam
> We all know and possibly used APL2000's products, or Dyalog, IBM APL2,
> and so. Some of us, in our earlier years, may have used VSAPL or
> APL.SV, or any of the other well-known
>
Try http://en.wikipedia.org/wiki/IBM_1130#Sample_APL_.5C_1130_session
and http://ibm1130.org/
There is an APL \ 1130 simulator that runs on Windoze.
Talk about retro!
Kym
urbancamo
> I wouldn't consider DEC APL "obscure"; one of the better porducts in
> the industry. I've been using their VAX-11 APL for about 10 years. No
> complaints - maybe a bit slow. I found it an excellent product with
> excellent manuals. Large systems in DEC APL have also been built
> by Mobil Oil R&D.
JK,
Are there any online manuals for DEC APL available? Or do you know
where I might be able to get some hardcopy manuals. I've been searching
high-and-low to no avail.
Regards,
Mark.
Gilbert Giappesi
But it is also fair that I mention I also used what I personnally consider the first "Personal Computer" (5100 and 5110) which picture is visible at the following link :
http://www-03.ibm.com/ibm/history/exhibits/pc/pc_2.html
I still have the 3 manuals that were delivered with, one of them with the original tape ... and one 8 inch diskette .
It was a pure "APLdelight" to use this box.
Gilbert
NoSpam a écrit :
Eric Landau
on IBM mainframes. It was developed at York University some time around
1970 (possibly jointly with Ryerson; my memory grows feeble with age).
I still have the manual for it, written by one J. Morgan Smyth in
1972. If there's a collector out there who wants to give it a good
home, I'd be willing to part with it for the cost of shipping. (If
interested, send an e-mail to aplsi at starpower dot net -- replies to
the address on this post will not reach me.)
Eric Landau, APL Solutions, Inc.
"Sacred cows make the tastiest hamburger." - Abbie Hoffman
RAV
You've prompted me to think of the "least-known" interpreter I've ever
worked with (and the worst-behaved, come to think of it). It was by
Agoronomic Teleprocessing Systems (ATS). At STSC around 1974, John
Gilmore, Shelley Rankin and I were tasked with converting a customer
application written in ATS APL to APL*PLUS. It was almost impossible.
For example, THEIR version of #VR and #FX was to use {del} as a
primitive function (!) to read and write DIRECTLY to the workspace
(functions came out as a vector of integers, obviously what was stored
internally). Of course, not only could you create some very odd
functions (it did little or no validation), but it was quite easy to crash.
--
Posted via a free Usenet account from http://www.teranews.com
Ted Edwards
> Star? Not from Seymour, but with some contribution from Canada :)
I was in charge of the development of APL*STAR. We had version one
ready and documented to go GA but the OS people were so far far behind
that the system never got the chance it deserved. We used to get copies
of the test bench marks that the FORTRAN people got and re-wrote them in
APL. They never beat us in execution time even though we counted in any
interpretive overhead. When there was a management upheaval, presumably
due to schedule slippage, my folk and I were to be transfered to the
COBOL project. One of us moved back to his home in California. The
remaining three of us went to MCM to do APL on the Intel 8008 (no, the
last two digits are not reversed). I demonstrated a portable (laptop)
version of that machine at the Copenhagen APL conference of 1973.
>> I used to work on a CDC 6600, and APLUM was available on that -- no
>> special characters (hell, remote access was a major technological
>> achievement, and not something you wasted on single-user terminals), and
>> my recollection of APLUM is that it was rather unstable, to the point of
>> being unusable
Greg Mansfield had an APL for the 6600. My group did some work on it
before the STAR project came a cropper.
>> Seymour Cray gave us a talk about future trends in hardware, &c, where he
>> mentioned "vectorisation", and pointed out that it was silly taking a
>> problem statement expressed in linear algebra, scalarising the thing so it
>> was expressable in Fortran, and then stuffing that code through a
>> vectoriser to spot the loops, in order to optimise them out -- and so they
>> (CDC) were looking at this thing called APL, as a more direct way of
>> working
>>
>> whatever happened to that initiative, I wonder?
See above. Pity that we never got a chance with STAR*APL. BTW, it had
nested arrays. :-) The design maximum WS size the APL system could
handle was a mere ~2*50 Bytes.
Ted
Ted Edwards
> But it is also fair that I mention I also used what I personnally
> consider the first "Personal Computer" (5100 and 5110)
Nope. It was at least a year after the MCM70.
Ted
markg
> But how about APL for the DEC machines, HP, APLUM, the APL from CDC
> before APLUM, Burroughs, Xerox Sigma, and others?
There were two APLs on the Xerox Sigma hardware, one from Xerox and an
earlier one named DREV APL. DREV was the Defense Research
Establishment Valcartier in Canada if I remember correctly.
I also programmed in APL on a Wicat microcomputer. That might have
been a port of APL.68000. Are we counting obscure ports as well as
implementations? :-)
Cheers,
..mark
hotair
keycaps after all. ) in Arden Hills (I think, could have been Toronto)
because we could not get anything to run on the OS. But it was just playing
around, OS people wanted us out of the way. But this was not on the 100,
perhaps on something like a Star 45? Can't remember the models.
"Ted Edwards" <Ted_Es...@telus.net> wrote in message
news:%dXmh.118021$hn.330@edtnps82...
Ted Edwards
> I remember running on APL*STAR (Actually typed APLPSTAR,
Not by us. :-) All of us were APLers before comming to the project so
we named the product "APL{to the power of}STAR.
> maybe I don't need
> keycaps after all. ) in Arden Hills (I think, could have been Toronto)
Could have been either. My group was at the Canadian Development
Division in Mississauga (suburb of Toronto). We developed the APL
system on the prototype (STAR 65, IIRC). At some point in, IIRC, 1972
there was to be a big demo of the STAR to some CDC vice presidents and
they wanted something that could show off the machine. I took two (in
case of a problem on one) diskpacks and flew to an airport near Arden
Hills. (Looking at City Select, Crystal rings a bell.) In half a day
and with two phone calls to Toronto, we had APL up on the STAR 100 under
their checkout operating system.
See, knowing that we were going to want to run under at least four OSs,
most of which were not well defined at that time, we invented two
concepts: The Ultimate Operating System and the Super Terminal. These
were what we wished the hardware and OS would look like to interface to
APL. We then made relatively small modules to interface to what was
there. We could talk to a card punch, a teletype, an IBM 2741 or the
(then new) Tektronix terminal with APL support.
> because we could not get anything to run on the OS. But it was just playing
> around, OS people wanted us out of the way.
When I was around, 70 or 71 until 73 (memory fades), there were only the
two machines the 100 in Arden Hills and the 65 in Toronto. When were
you there?
Gilbert Giappesi
Gilbert
Ted Edwards a écrit :
hotair
Toronto just before Christmas at a meeting about the OS (miserable trip). So
it would have been after that, and there was a spring meeting at Langley
where we pulled the plug on STAR. But I can't recall when that was. I am
pretty sure it was winter still or again, so either I was there in early 72
or early 73; but that was too long ago and I kept nothing from that episode.
"Ted Edwards" <Ted_Es...@telus.net> wrote in message
news:3Ubnh.121166$hn.69645@edtnps82...
Curtis A. Jones
...
> interpretive overhead. When there was a management upheaval, presumably
> due to schedule slippage, my folk and I were to be transfered to the
> COBOL project. One of us moved back to his home in California. The
> remaining three of us went to MCM to do APL on the Intel 8008 (no, the
> last two digits are not reversed). I demonstrated a portable (laptop)
> version of that machine at the Copenhagen APL conference of 1973.
>
There's an article on the MCM/70 in the Computer History Museum's
magazine "CORE".
Zbigniew Stachniak, "The MCM/70 Microcomputer", Core 4.1, Sep. 2003,
pp. 6-11.
http://www.computerhistory.org/archive/CORE4.1.pdf
A reprint of just this article is at
http://www.xnumber.com/xnumber/MCM_70_microcomputer.htm
Zbigniew Stachniak has a helpful Web site:
http://www.cse.yorku.ca/museum/index.htm
The virtual tour starts with the MCM/70.
Curtis Jones
TaliesinSoft
(in article <1167745602.8...@42g2000cwt.googlegroups.com>):
> I would be interested in any comments, notes, interesting tidbits, an so on,
> about some of these not-so-well-known APL interpreters.
In the early '80s Analogic Corporation developed "The APL Machine" which was
an array processing computer designed to be programmed only in APL. There
were actually three processing units, the user's workstation, an IBM PC,
where programs were entered and edited, a Motorola 6800 processor which ran
the APL interpreter, and the Analogic array processor which executed the
primitives. At the time of its introduction The APL Machine was likely the
fastest APL system available. Although a technological success The APL
Machine was a marketing failure. The initial version supported a single
process at a time. At the time of the discontinuance of the project the
design had been completed to allow multiple users. As an aside, an unusual
aspect of The APL Machine was that the library of workspaces was organized
such that a single function or value which was shared by many workspaces
existed only once in the library. Several of the members of The APL Machine
project, myself included, had previously spent a number of years with
Burroughs implementing APL\700.
--
James Leo Ryan ..... Austin, Texas ..... talies...@mac.com
Rick Mayforth
UMASS and was involved in the APLUM development project from 1972-1975. Our
goal was to develop a powerful and efficient CDC 6600 APL, and we did. After
graduation I got a job at CDC in Minneapolis. As an APL person, my first job
was to convert a number of applications that CDC was running using STSC's
(IBM-based!) service to run in house on CDC hardware. I tried to use the APL
2.0 product that was in development at the time by CDC Canada, but it was
slow and lacking sufficient function to compete with either APLUM or STSC's
APL*PLUS. After trying to use it, I got a copy of APLUM and successfully
converted a number of applications. This led to convincing CDC management to
adopt the UMASS version as CDC's official APL 2.0 product. In the 6 years
that I was at CDC, all my work was oriented to APL. The APLUM product was
stable and got good suppport from the UMASS development team. We had no
major stability problems of which I am aware; we ran a number of production
systems internally at CDC with it.
"Ibeam2000" <Ibea...@gmail.com> wrote in message
news:1167745602.8...@42g2000cwt.googlegroups.com...
Don Wiss
>I would be interested in any comments, notes, interesting tidbits, an
>so on, about some of these not-so-well-known APL interpreters.
What about phantom interpreters? Like the one that Microsoft was planning
to come out with? I had a sheet of paper with the specs. It got tossed when
I tossed all my CP/M literature (except my original WordStar). It is the
only CP/M thing that I wish I still had. Does anyone have a copy?
Don <www.donwiss.com> (e-mail link at home page bottom).
Martin²
>It is the only CP/M thing that I wish I still had. Does anyone have a copy?
Not what you asked for, but I think I still have a copy of MicroAPL for
CP/M, gives you 29kb workspace :-)
Regards,
Martin
Doug White
>
>"Ibeam2000" <Ibea...@gmail.com> wrote in message
>news:1167745602.8...@42g2000cwt.googlegroups.com...
>[...]
>
> But how about APL for the DEC machines, HP, APLUM, the APL from CDC
> before APLUM, Burroughs, Xerox Sigma, and others?
>
> And how about things like Vanguard APL for the Z80?
>
> I would be interested in any comments, notes, interesting tidbits, an
> so on, about some of these not-so-well-known APL interpreters.
I used to use APL-3000 on an HP 3000 mainframe computer back in the late
70's. It was actually a nice implementation. It was semi-compiled in
that it would compile (to some extent) the code in a function when you
exited the function editor. The claim was that it would run rings around
other APLs. Unfortunately, it didn't work well on the 3000 architecture,
especially if there were other users on board. I had to run my work at
night to avoid getting lynched because almost any APL calculation would
grab 75% of the system resources. I was doing Monte Carlo simulations of
filter circuits, and they took about a half an hour to run. The rumor
was that they got into some law suits over the initial claims they made
for it, and APL got a black eye at HP. They never touched it again. The
language manual was great, and I still have a copy somewhere. The color
diagrams of how some matrix operations work are quite nice.
They also had APLGOL, which was some sort of blend of APL & Algol.
Doug White
Don Guinn
Doug White wrote:
>>"Ibeam2000" <Ibea...@gmail.com> wrote in message
>>news:1167745602.8...@42g2000cwt.googlegroups.com...
>>[...]
>>
>>But how about APL for the DEC machines, HP, APLUM, the APL from CDC
>>before APLUM, Burroughs, Xerox Sigma, and others?
>>
>>And how about things like Vanguard APL for the Z80?
>>
>>I would be interested in any comments, notes, interesting tidbits, an
>>so on, about some of these not-so-well-known APL interpreters.
>
>
I played with an APL for Data General computers. I think it worked on
the MV8000 but I might be wrong. That was in the 1980s. I moved a lot of
programs I had written on the IBM mainframe and they worked without
modifications. It was the first APL I saw that had online documentation.
Their manual was online and you could get to function definitions
directly. Nice.
Unfortunately, the group I was in at that time was heavily FORTRAN
oriented. So it really went nowhere for our company.
sie...@allegro.com
Doug White wrote:
> I used to use APL-3000 on an HP 3000 mainframe computer back in the late
> 70's. It was actually a nice implementation. It was semi-compiled in
It was a fantastic APL ... probably the most powerful, inventive one of
its time.
But, it was also the slowest one around, to the point of being unusable
for most users.
The really sad thing is that when MPE was migrated to PA-RISC, they
didn't add
the two instructions necessary to the Classic HP 3000 emulator to allow
it to
run APL ... because it would have been much faster on PA-RISC with a
good virtual
memory implementation.
APL/3000 was available for the HP 3000 Series III, but required a
firmware upgrade.
IIRC, it was also available (as a firmware upgrade) on the 3000/30 and
3000/33, but
not on any faster models. I saw the unreleased firmware ROMs for APL
for the
3000/40 and /44 in Leon Leong's desk drawer sometime in the mid/late
1980s.
> The rumor
> was that they got into some law suits over the initial claims they made
> for it, and APL got a black eye at HP.
I remember being told about the lawsuits by one of the programmers
supporting APL/3000.
He said that as soon as the lawsuit was finished, they'd be dropping
APL/3000 from
the product line. He said that they were able to produce documents
that showed that
HP had recommended against using APL for whatever project the lawsuit
was about.
Later, APL/3000 inspired a triva question about MPE V:
What's the only way to run a program on MPE and not have it say "END
OF PROGRAM"
when it finishes?
Rename the program to be "APL.PUB.SYS" and invoke it by typing: APL
(That triggered the command interpreter to run the program, and since
it was APL,
it didn't say "end of program" at the end.)
Stan Sieler
sie...@allegro.com
>
> But how about APL for the DEC machines, HP, APLUM, the APL from CDC
> before APLUM, Burroughs, Xerox Sigma, and others?
I enjoyed using Burroughs APL in the mid/late 1970s, on a B6700.
I remember being at the Burroughs booth at the APL 76 conference ...
some employee
of another APL vendor was going around to all the booths, entering
some APL expression that locked up the competitors but that they
handled efficiently
(something like + / iota 1000000 ?). He entered it into the Burroughs
APL interpreter,
and the terminal locked up ... but the other terminal in the booth
continued to function.
He was disappointed. He'd apparently never heard of dual CPU computers
:)
The APL interpreter had spawed one server process per CPU, and he'd
only locked up one!
(To be fair to him , in the 1960s/1970s Burroughs was way ahead of the
other mainframes in
multi-processing and virutal memory.)
(To be more fair, although I remember the lockup, and the dual CPU
solution, the details
are now a bit fuzzy, and seem a bit hard to explain, unless the APL
interpreter was doing
its own time sharing ... which would be unusual on a MCP system, where
you'd normally
design it to spawn one interpreter process per user.)
One nice thing about Burroughs APL was that, like all other software
for the B6700,
it came with the source code. I implemented the ability for CANDE
users to send
messages to APL users, and vice versa.
At that same conference, IIRC, APL/3000 was announced, which used the
HP 2641A CRT terminal ... which had the APL character set. A lot of
APL users were
excited about the terminal, until we found out that they "cheated" to
implement
overstrikes. The terminal firmware knew what character was at a given
position....
if it received <quad> <backspace> <prime>, it didn't merge the bits of
the graphics...
no, it replaced the quad character in RAM with some internal character
that meant
<quad-prime>. While a clever solution (implementing overstrikes
without having the
cost of implementing a true bitmap display), this meant that it only
supported those
overstrikes that it knew about ... and that was just the overstrikes
APL/3000 used.
Burroughs APL used most of those *and* others, so we never bought any
of the terminals.
CANDE and APL...background.
The normal way interactive users on MCP (on a B6x00 or B7x00)
interacted with the
computer was by logging on to a Message Control System (MCS) called
CANDE
(Command AND Edit (rewritten by Darryl High, IIRC, circa 1971, named
after a similar
earlier system). APL was an alternative MCS. When you walked up to an
idle terminal,
you could select which MCS to sign on to.
I had a Tektronix 4013 terminal (APL character set), which meant that
when I was in APL
I couldn't get messages from CANDE users, nor send messages to CANDE
users.
So I added commands to let me see who was logged on to the opposite MCS
and
send messages.
The next problem, of course, is that any uppercase letter in a message
from a CANDE user
to an APL user (using a terminal with APL character set) is that those
uppercase letters
would be "greek". E.g., delta instead of "G"). We had to prefix such
messages
with a "switch to normal character set" and suffix with "switch back
to APL character set"
so they'd be legible!
Since terminals were connected via a Datacom Processor (programmed in a
high-level
ALGOL lile language, of course...this is Burroughs, man!), Howard Green
of Burroughs
Rancho Bernardo implemented the ability to have multiple sessions from
a single
terminal. (Similar to how many Linux systems allow multiple virtual
consoles today,
but this was in 1977.) He added code to remember which MCS each
session was using,
and would echo back the proper "switch to character set <X>" escape
sequence if
you switched from a CANDE session to an APL session (or vice versa).
Stan Sieler
sie...@allegro.com
TaliesinSoft
(in article <1168548141....@77g2000hsv.googlegroups.com>):
> (To be more fair, although I remember the lockup, and the dual CPU solution,
> the details are now a bit fuzzy, and seem a bit hard to explain, unless the
> APL interpreter was doing its own time sharing ... which would be unusual on
> a MCP system, where you'd normally design it to spawn one interpreter process
> per user.)
I was the head of the APL\700 team from the projects instigation in late 1969
until 1978. Other members of the project included Glenn Martin, David Frye,
Jim Williams, Ron Murray, Ken Carvin, Harvey Bingham, and Ron Coleman.
From the technical standpoint I was the designer of the logic used by the
interpreter which was a bit different from the other APL interpreters of the
time in that each line of APL code, upon initial execution, was transformed
into a reverse Polish notation which was used for all subsequent executions
of that line until such time as there was a valence change in one of the
constituent defined names, at which time the line was "re-compiled" into the
revised reverse Polish, and if that wasn't possible the appropriate error
message was produced. An amusing (sometimes considered annoying) aspect of
that technique was that when an expression or function was displayed it was
in the so-called "canonical" form with such as redundant parentheses removed.
There were two queues in which a user could be placed. The higher priority
queue was where the user who had just entered an "immediate" expression was
placed. The lower priority queue was where all user's were placed who had
entered an expression that took longer than the allocated slice in the
immediate queue. The result was snappy response when such was expected.
At the time the APL\700 project was launched the available workspace sizes on
the then available APL systems tended to be set in the 30 to 40 KB range. The
initial implementation of APL\700 had a workspace address range of what was
then an astounding 1 MB. That was later changed so that workspaces could be
massively larger.
Markus Triska
> interpreter which was a bit different from the other APL
> interpreters of the time in that each line of APL code, upon initial
> execution, was transformed into a reverse Polish notation which was
I find it strange that this wasn't more common, since a stack-based VM
allows for compact (byte-)code, and APL can be compiled easily into
it. Did other interpreters still operate directly on the syntax tree?
All the best,
Markus Triska
dluk...@gmail.com
Russian mini- and micro-computers with PDP-11 (DEC) architecture. The
author is Andrew Kondrashev.
http://portal.acm.org/citation.cfm?id=97848&coll=portal&dl=ACM
The main features of the APL system:
1) Supporting APL symbols on ordinary keyboard for alphabetical
monitors. As I remember, "_P" was used for "ro" , "_I" for "iota".
The graphic monitors supported standard APL symbols. Also it was
possible to use standard APL symbols on some popular alphabetical
monitors after the replacing of character-generating chip.
2) The APL-machine based on micro-computer. The executable APL
interpreter was loaded from EPROM card right away the computer is
turned on. The computer disks were used only to save and load
workspaces and data-files. Also it was possible to add auto-loading
workspace to this card and have digital "diskless" APL-device.
3) The APL-network based on RT-11 operational system. The APL-machines
can share workspaces, data-files and use printers and plotters on
central mini-computer.
4) The easy-to-use program interface to call executable modules. We
widely use APL and Assembler together for automation tasks. I am still
proud of my run-time application to support CAMAC which had been
implemented 20 years ago.
Best wishes to colleagues,
Dmitry Lukyanov
Obninsk,Russia