The history of the Interlisp Programming Project
Larry Masinter
Graphical user interfaces:
In the late '70s, the first initial graphical user interface for
Interlisp was built, using Interlisp-10 on the timesharing system
(Maxc, a PDP-10 clone), with the display manager running on an Alto.
While these were published and demonstrated at conferences,
they never made their way out as products. This system was called
DLisp.
* Warren Teitelman. "A Display Oriented Programmer's Assistant". Xerox
PARC report CSL-77-3. "A version of this paper appeared in Proceedings
5th IJCAI, Vol 2, pp 905-915; MIT; Cambridge, MA August 1977".
* Robert F. Sproull. "Raster Graphics for Interactive Programming
Environments". Xerox PARC CSL-79-6.
"A shortened version of this paper appeared in Computer Graphics,
Summer, 1979."
* Mitchel L. Model. "Monitoring System Behavior in a Complex
Computational Environment". Xerox PARC CSL-79-1, January 1979, also
Stanford University Computer Science Department Report CS-79-701.
Alto Lisp:
The Alto Lisp effort Alto Lisp was a separate development, primarily
by Peter Deutsch and Willie Sue Haugland (now Orr). Alto Lisp was an
implementation of the core Interlisp language; it had no graphical
user interface.
* L.P.Deutsch. "A LISP Machine with Very Compact Programs". Third
International Joint Conference on Artificial Intelligence, Stanford,
CA., August, 1973.
* L.P.Deutsch. "Bytelisp and its Alto Implementation". 1980 LISP
Conference, Stanford, CA, 1980.
* L.Masinter, L.P.Deutsch. "Local Optimization in a Computer for
Stack-based LISP Machines.", 1980 LISP Conference, Stanford, CA.
DoradoLisp, DolphinLisp:
Alto Lisp was later modified, enhanced, and ported to various
microcoded "D" machines of Xerox design: Dorado, Dolphin, Dandelion,
Daybreak. The first port was to the Dorado processor, although the
Dorado was not released as a product until well after the Dolphin
became the Xerox 1100 Scientific Information Processor. (I think there
was some corporate sensitivity to having a product identified as a
'computer'.)
* R.Burton, L.Masinter,W.S.Haugeland,R.Kaplan,B.A.Sheil, "Overview and
implementation status of DoradoLisp", 1980 LISP Conference,
Stanford, CA.
Interlisp-Maxc:
There was a separate 9-bit-byte-coded Lisp instruction set for the
Maxc system. Unfortunately, this didn't result in a significant enough
improvement in performance or space for it to be worth the cost of
maintenance of separate versions of compiled code.
"The Maxc Systems", Edward R. Fiala, IEEE Computer, May 1978.
Interlisp-Jericho:
There was a machine designed and built at Bolt Beranek & Newman called
the 'Jericho'; it had a full Interlisp-D implementation. It was never
released, and I don't remember ever seeing any documentation about
it.) However, we did maintain 'Jericho-compatibility' software in the
Interlisp sources for many years.
Interlisp/360-370:
* Anders Haraldson, "LISP-details. Interlisp/360-370".Uppsala
University, Datalogilaboratoriet, Department of Computer Sciences,
1975.
Interlisp-VAX:
* L.Masinter. "Interlisp-VAX: A Report." Stanford University CS Report
No. STAN-CS-81-879, August 1981.
* R.Bates,et al. "Interlisp-VAX Users Manual, First Edition,
Preliminary Draft." December, 1982.
"Interlisp-VAX is sponsored by DARPA under contract number MDA
903-81-C-0335".
Interlisp-D:
The addition of a 'graphical user interface' to the 'personal
microcoded machine' came in two stages; first the addition of
graphical output contexts (display streams) in 1980, and later the
addition of a real window system in 1981.
Environment:
Programming environment tools evolved along a couple of lines:
Editing:
I think the history of the 'tty' editor thru DEdit and SEdit was
descussed adequately. SEdit was originally done as an editor for
Interlisp only by Mike Dixon, and only ported and modified to deal
with Common Lisp, packages, and other elements later.
The most frequently discussed issue in Lisp environments was the
distinction between "text-based" and "resident" environments. Most
programming environments are 'text-based': you edit files and load
them. Interlisp, from the beginning, took the 'resident' approach, in
the sense that it was always based on the model of editing program
structure in place, and then writing out the appropriate elements of
program structure in order to save state.
Program management:
Since the environment was 'residential', it was important to keep
track of what changed, and evolve strategies for periodically
rewriting source and compiled files to correspond to current program
state. This evolved from simple "prettydef" commands (write out
current program state), to the more complex "File Package" facilities,
which kept track of which program elements belonged with which files,
when they were changed, and the state of the editing process. (The
idea of having the editor notify some global state that some program
element changed was some kind of breakthrough.) Most of this work was
through the '70s, although there was an attempt at some point to
regularize a set of facilities for programmatically manipulating
program elements ("take the definition of X as a macro from file Y and
put it in file Z"). Some typical facilities included auto-time-stamp
and initials for individual functions when edited, writing out the
list of changes between one version and the next at the top of a file,
automatic program formatting with different fonts for user functions,
cross references in program listings.
Error correction:
DWIM, "Do What I Mean", has fallen into disrepute. No program system
today would have the audacity to 'guess' what a programmer might have
meant in the face of an error. At the time, it seemed like a good
idea.
Programmer History:
The idea that the environment might keep track of previous events
was novel at the time.
In addition to the Teitelman&Masinter 1981 IEEE Computer article and
the "Power Tools" in Datamation:
* Teitelman, W. "Toward a Programming Laboratory," Proceedings of
First International Joint Conference on Artificial Intelligence.
(1971?).
* Teitelman, W. "Automatic Programming- The Programmer's Assistant."
Proc. Fall Joint Computer Conference, December 1972.
* Teitelman, W. "Do What I Mean." Computers and Automation, April 1972.
Other references:
Stephen H. Kaisler. INTERLISP, The Language and Its Usage. John Wiley
& Sons, Inc, ISBN 0-471-81644-2, 1986.
Release names: we decided to name releases out of the Harvard Concise
Dictionary of Music. At first, the names were haphazard, until we
decided to use names in alphabetic order. I don't remember the order
of Allegro, ConBrio, Key, and Wind; these were primarily reworks of
the microcode, instruction set, and low-levels of the system to get
better performance. (Key moved some of the keyboard handling out of
BCPL into interrupt-driven Lisp.)
Michael Denber's post covered release dates & through ConBrio and
beyond.
================================================================
Postscript:
The tools I have now for debugging C are far superior to the tools I
used to have for debugging microcode. Emacs is much better than Teco,
which we used for the PDP-10 assembler code in Interlisp-10.
--
Larry Masinter (masi...@parc.xerox.com)
Xerox Palo Alto Research Center (PARC)
3333 Coyote Hill Road; Palo Alto, CA USA 94304
Phone: (415) 812-4365 Fax: (415) 812-4333
Arun Welch
one person request off the list due to the volume.
The most frequently discussed issue in Lisp environments was the
distinction between "text-based" and "resident" environments. Most
programming environments are 'text-based': you edit files and load
them. Interlisp, from the beginning, took the 'resident' approach, in
the sense that it was always based on the model of editing program
structure in place, and then writing out the appropriate elements of
program structure in order to save state.
It's interesting to see some of this come around again. At their users
group meeting at LUV 91, Franz said they're looking into a residential
programming environment for some future release. While CL is mostly
text-based, I feel that CLOS has a mostly residential feel to it.
Larry again:
The tools I have now for debugging C are far superior to the tools I
used to have for debugging microcode. Emacs is much better than Teco,
which we used for the PDP-10 assembler code in Interlisp-10.
OK, you're comparing debugging C to debugging ucode or assembler. Out
of curiosity, how would you compare the current crop of lisp "debugging
environments" to Medley's? My opinion is that they don't, but I'm
biased.
Michel sez:
Medley was the first release to run on Suns. I
understand that there will be no more new names, just incremented
version
numbers.
I seem to remember that this was required by Xerox at the EnVos spinoff.
When Koto was first released into beta I asked Marty Raim what the heck
a "koto" was. He said that they'd been searching for a "k" name at the
time that a bunch of them went to dinner at a Japanese restaurant, where
they had a koto player providing background music. On finding out what
the instrument was, they decided they'd found a name.
Putting Michel and Larry's messages together, the versions were:
Allegro, ConBrio, Wind, Key: order unknown.
Chorus, Fugue, Carol, Harmony, Intermezzo, Koto, Lyric, Medley.
I seem to remember Carol before Fugue, but I could easily be wrong. The
oldest manual I've got is a little green one dated September, 1982, but
it doesn't talk about the version number. It talks about booting the
Alto, as well as about the window system. It certainly predates my
coming to the LAIR.
...arun
Arun Welch
from Larry's last message.
...arun
Herb Jellinek
From: we...@cis.ohio-state.edu (Arun Welch)
Newsgroups: comp.sys.xerox
Date: 4 Nov 91 09:43:16 GMT
References: we...@cis.ohio-state.edu (Arun Welch)
Organization: Info-1100 Mailing List
[...]
Putting Michel and Larry's messages together, the versions were:
Allegro, ConBrio, Wind, Key: order unknown.
Chorus, Fugue, Carol, Harmony, Intermezzo, Koto, Lyric, Medley.
I seem to remember Carol before Fugue, but I could easily be wrong. [...]
...arun
No, Carol definitely came after Fugue. Though I think we had already
decided on using alphabetical order for release names, I recall
someone remarking, "That's 'Carol' with a 'G.'"
Guess you had to be there.
Herb Jellinek, he...@frox.com
Jon L White
feel to it.
There's no doubt that Danny Bobrow's hand is showing here. See especially
the "reconstructor" parts of the AMOP proposals. If Moon and the other
Symboloids had had their way . . .
The more interesting part of the eventual Interlisp design was the stuff
approaching a "programmer's assistant", such as the hooks that the editor
had into the rest of the system so that when you edited the code for some
definition FOO, all the other definitions that "depended" on this one
would somehow get marked. I may be overstating the capabilities a bit,
but that was certainly the directions (as opposed to, say, DWIM, which
was simply programs-mucking-around-with-programs taken to a certain
logical extreme).
And of course the parallel to the scope of Lucids "Cadillac" system
can hardly be overlooked here. I think "Cadillac" will be called a
"Programming System" rather than just a "programming development
environment", becaue it intends to encompass the best-and-brightest
ideas of the residential notion. E.g., it is not just a programming
language (such as C++); it covers all the kinds of dependency hooks,
monsterscoping analyses, and persistency of stuff, etc. that stand
out in the residential notion.
-- JonL --