Newsgroups:   comp.lang.apl
Path: watmath!watserv1!torn.onet.on.ca!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!uunet.ca!geac!itcyyz!yrloc!intern
From:         loc@yrloc.ipsa.reuter.COM (Leigh Clayton)
Subject:      Re: Embedding J/APL/etc. into a program... (like elisp in EMACS)
Message-ID: <1992Jun16.015748.11952@yrloc.ipsa.reuter.COM>
Sender: intern@yrloc.ipsa.reuter.COM (Intern via QUADRAM)
X-Telephone:  +1 (416) 364-5361 Fax +1 (416) 364-2910 Telex 0622259
Organization: Reuters APL Software Division
X-Mail:       1900/2 First Canadian Place, Toronto, Canada, M5X 1E3
Date:         16 Jun 92 01:18:39 UT

 In response to Allan Stuart MacKinnon Jr. --

 APL\1130 release one was a 1-inch thick card deck, complete, and that included
drivers for disk and typewriter. It was missing a few primitives (like domino)
but was reasonably complete for what we now would call a 'standard' APL (it had
no quadnames, no file system, no general arrays).

 My point is that APL itself is not a complicated thing to implement (if you
know how to do it). The things that make it big are usually environmental
(interfaces to the terminal, to the OS, to a file system, AP's, and so forth).

 For the language I'd suggest that you simply adopt the ISO APL standard (IS
8485); that way you don't need to write documentation for it. If you find
something useless for your application or hard to do, throw it out and document
*that*. This has the benefit that your documentation is easier the more you do
:-).

 Even though you can't use it directly, you may benefit from looking at someone
else's PD implementation. Iapl is pretty close to the standard, for example
[if they'll give you the source ... I assume it's well documented :-) ].

.../Leigh

-----------------------------------------------------------
Leigh Clayton                     loc@yrloc.ipsa.reuter.COM
    -or-                        loc@ipsaint.ipsa.reuter.COM
