Scheme, Coral Lisp
Volume Number: 4
Issue Number: 3
Column Tag: Lisp Listener
MacScheme vs Coral Lisp 
By Paul Snively, ICOM Simulations, MacTutor Contributing Editor
Paul Snively is one of our favorite people; a long time MacTutor fan, and
contributor, we are glad to have this contribution from him. Here are some notes Paul
sent that will bring all his fans up to date on what he has been doing.
Letter to MacTutor
“Well, here it is--after a period of time that was entirely too long on two counts
(too long both in terms of time between payment and delivery (roughly nine months)
and time between receipt of software to support this article and delivery (about four
months)). Good grief; look at those parenthesis--you can tell I’ve been working in
Lisp lately!
Let me congratulate you on the apparent ongoing success of MacTutor as an
organization, and upon the consistently high overall quality of the content (my own
work notwithstanding). The article on the writing of custom printer drivers was
particularly welcome, and there is much more than could be done there. In particular,
a LaserWriter driver that doesn’t require the “Laser Prep” file (i.e. one that
generates pure PostScript without any Apple-proprietary PostScript macros) would
be a most welcome project from a number of standpoints, I think.
In case you might be curious as to what I’ve been up to lately, ICOM Simulations,
Inc. has kept me pretty busy from day one, although the situation seems to be
intensifying lately. Early on in my time with ICOM, there was “TMON Plus/TMON
Professional” (depending upon whom you talked to) to work on. Unfortunately that
project met an early demise when it became clear that Waldemar would not be able to
complete the kernel before he had to return to MIT after the summer.
After that we concentrated on TMON 2.8, which was released at Boston.
Unfortunately, it isn’t everything that we might wish that it was (in particular, the
lack of disassembly of ’020 and ’881 opcodes is hurting us, as is the funny-looking
display when you’re on a Mac II in multiple bit-planes). However, our customers
seem happy to have something that at least will run on a machine with an ’020, and it
does have a few additional nicities (such as the INIT loader, the Programmer’s Key
INIT, better documentation, no VBL tasks while in TMON, etc.)
Lately, and in some ways con currently with all of this, we continue to write
MacVentures. There’s a certain irony in being the developers of the de facto standard
Macintosh debugger and also of a series of adventure games. Apple makes sure that
we’re kept on top of new System Software developments (we tested Juggler, of course,
for some time) because of TMON, but the applications that benefit from the knowledge
first are a bunch of games! (I’ll bet we have the only MultiFinder-aware adventures
on the market.) Also ironic is the fact that the MacVenture kernel seems to be a good
testing environment for all kinds of weird issues like window management,
application-defined events, synchronous and asynchronous I/O, and the like.
Speaking of which, here’s a bug note for MultiFinder 1.0 that you may want to
publish. If your application is MultiFinder-aware and has the canBackground bit set
in its SIZE resource (i.e. it will run in the background under MultiFinder), and the
application posts an application-defined event (appEvt1-appEvt3; appEvt4 is for
Suspend, Resume, and mouseMoved events), the event will not necessarily get sent to
the application that created it--it may go to some other application running under
MultiFinder. Needless to say, this can cause your application and the other application
all kinds of headaches if you rely on application-defined events to work properly (the
MacVentures historically have used appEvt1 and appEvt2 for won/lost events and
sound events; the kernel has been rewritten to be a state machine now that uses no
application-defined events).
It’s really been fun Lisping lately; I’d forgotten how nice it is to work in a good
Lisp development environment. It’s been so nice and so accessible that I’ve gotten some
really interesting ideas that I think (and in some cases know) could be implemented
fairly easily in Lisp. One thing that comes immediately to mind is a Display PostScript
implementation (Lisp is great for writing interpreters). Another thing that comes to
mind is porting Xerox’s “NoteCards” program from their Lisp workstations to a Mac II
running Common Lisp. The world seems to love HyperCard, so they should faint over
“NoteCards.”
Well, again, thanks for everything! Please say hello to the rest of the gang for me
(and please tell Shelley that I enjoyed talking to her again very much). Hopefully I’ll
see you in August!” Sincerely, Paul Snively
The Cheap AI Workstation
The Macintosh II has been around for a few months now, and much of the furor
has died down, aside from gripes from disgruntled Macintosh II owners that Apple has
been less than speedy in coming out with their own color monitor, or that more SIMMs
are hard to come by. In some ways, the honeymoon is over, and we’re beginning to
hear the complaints. People aren’t as blown away by the performance of the
68020/68881 as they thought they would be. Some software, particularly those
packages that insisted on breaking some of Apple’s clearly-defined rules, doesn’t work
on the Macintosh II. Virtually all games that do animation of any sophistication at all
don’t work because they use the alternate screen buffer, which the Macintosh II
hardware lacks.
My personal opinion is that, at least for developers if not for the end users, the
honeymoon for the Macintosh II is ending before the marriage has even been
consummated. I feel that there’s been too much emphasis on why the Macintosh II is
perhaps not as great a “souped-up Mac Plus” as some people might have wished, and
not enough emphasis on why the Macintosh II is probably the most bang for the buck
that you will be able to get in a low-end workstation for the next few years.
When I was a computer science student in college, I thought the academic scene
was pretty boring. By the time I was a freshman in college I’d been programming for
four years already. Taking courses called “Advanced Programming Techniques” that
consisted of learning the PL/I programming language and learning about such
ostensibly innovative data structures as “linked lists” and the algorithms to
manipulate them impressed me about as much as learning Latin would have as a
high-school student (in fact, I find Latin a great deal more applicable to real-world
situations than PL/I)!
That was the obvious side of my college experience. The non-obvious side of my
college experience consisted of getting to know two fascinating individuals and the
language in which they seemed best able to express their concepts. The people were
Douglas Hofstadter, author of Gödel, Escher, Bach: An Eternal Golden Braid, and Daniel
Friedman, author of The Little LISPer. The language in question was, of course, Lisp,
or at least one or two interesting variations on it.
I learned Franz Lisp and Scheme on the VAXCluster at school on my own time. It
was a wonderful environment to work in, and I spent many hours in front of my Model
I TRS-80, which was connected to the phone in my dorm, and from there connected to
the computing network on campus. I had access to a wonderful Lisp structure editor,
and, Lisp being the kind of language that it is, I spent a fair amount of time customizing
my copy of the editor to suit my tastes. It was fairly easy, if also fairly dangerous,
because I could literally change the editor, and as soon as I entered the change, it would
take effect. Needless to say, it was quite possible to goof and do something to make the
editor totally unusable this way, so working on a backup copy was always a good idea.
But to me, Lisp was always the ultimate interactive development environment, and the
concepts behind it were extremely interesting.
By now you’re probably wondering where all of this is leading up to. Well, bear
in mind that I was working on a large VAXCluster with lots of disk space and lots of
memory--and lots of horsepower. I got a Lisp for my TRS-80 at one point, but it
turned out to be a very frustrating thing, what with the limited RAM and CPU power of
most 8-bit micros. I basically resigned myself to never working in such an
environment again, and since I had become entrenched in the microcomputer world, I
figured that I’d never have a good Lisp system.
Time went on, and although decent Lisp systems got smaller and created a whole
new class of machines called “workstations,” which had names like Symbolics and Lisp
Machine, those, too, were machines with a lot of horsepower and RAM and disk space,
dedicated to doing one thing: running Lisp, and running it well enough so that
professional AI re searchers could do meaningful work. They were obviously still way
out of my league as an interested amateur, with price tags well into the five figure
range.
But the Macintosh II exists now, a machine with an MC68020 microprocessor,
an MC68881 math coprocessor, anywhere from 1 to 8 megabytes of RAM, and as much
disk space as you can afford. It’s not a dedicated Lisp machine, but with a couple of
Macintosh products available, it might as well be, and it’s a lot cheaper.
I picked up two Lisp implementations at the Boston MacWorld Exposition. One of
them is a newcomer, released at the show. The other has been around somewhat longer,
but has undergone some evolution and deserves a serious look. What is perhaps most
interesting about the two products is that while they both cover extremely similar
ground, because of their underlying philosophies they will appeal to different people
and for different reasons.
MacScheme+Toolsmith 1.0 is the older of the two products that I have, or at least
MacScheme is. In chapter one of the documentation, it says: “MacScheme, introduced
in August 1985, was the first microcomputer implementation of any modern Lisp
standard.” It’s a rather bold statement, and one open to question if you have used some
of the other Lisp offerings on other machines, particularly any of the Golden systems
on the IBM PC-class computers. On the other hand, if you accept Semantic
Micro systems’ statement that “Scheme is one of the two major dialects of Lisp,” and
understand that the other one is Common Lisp, and also know that until very recently
there was no such thing as a complete microcomputer implementation of Common Lisp,
then the statement is certainly true.
MacScheme historically has been a semi-compiled, byte-code oriented system,
but with the addition of the Toolsmith code, MacScheme has become a language capable
of compiling to native code and creating standalone applications written entirely in
Scheme. Scheme aficionados should find this very exciting. Complete source code for a
simple text editor is included to help show how to create applications. The choice of a
text editor is an interesting one; I guess the message is that “Lisp isn’t just for AI
anymore,” which is certainly a valid point.
If there’s a general way to describe Scheme, it has to include the word “elegant.”
Scheme was designed with an eye toward simplicity and power. It tends to be the
smallest implementation of Lisp for any given machine, and MacScheme+Toolsmith is
no exception to that rule; the kernel is about 75K in size, and a goodly-sized heap
image is about 182K. MacScheme+Toolsmith fits pretty well in a one megabyte
machine, as long as you’re careful about hogging up valuable RAM with things like
debuggers and INITs and sounds and so forth.
MacScheme+Toolsmith 1.0 is shipped on three 800K disks, labelled
“Toolsmith,” “Library,” and “Miscellaneous.” Don’t be misled by the fact that the
whole product takes 2,400K of disk space to ship; you can copy the Toolsmith disk,
boot from it, and accomplish a great deal without ever looking at the other two disks.
The Toolsmith disk contains a System Folder, the MacScheme+Toolsmith application, a
generic Scheme heap image file, and a Toolsmith heap image file. Double clicking the
application will cause MacScheme+Toolsmith to look for “Scheme.heap;” you can
double-click any heap image file to cause MacScheme+Toolsmith to load it instead.
Once MacScheme has come up, you’ll see one thing that immediately sets it apart
from Allegro CL, the other Lisp environment that I wish to look at: MacScheme has a
fairly spartan user interface. It’s too easy to be put off by the minimalist appearance
of the product. Avoid the temptation. While the tools to tinker with MacScheme may
not be as obviously up front and “Macish” as they are in Allegro CL, they are, for the
most part, there. MacScheme is a complete Scheme implementation, and, like Scheme
Referenced by (1):