Talk:Interlisp
 | This article is rated Start-class on Wikipedia's content assessment scale. It is of interest to the following WikiProjects: | ||||||||||
| |||||||||||
Envos was reincarnated as Venue Corp., and Interlisp-D is now known simply as "Medley" (TM) which was the name of the last release of Interlisp-D at Xerox. Later Interlisp-D releases had names rather than numbers (Koto, Lyric, Medley).
comments/additional history[edit]
See https://groups.google.com/d/msg/comp.sys.xerox/li_TlcUgtbc/MxGkh2G817gJ for history until 1991 — Preceding unsigned comment added by 24.6.174.39 (talk) 04:06, 28 July 2018 (UTC)
Intro:
"Interlisp was a version of the Lisp programming language" doesn't really capture what it was: what was interesting about Interlisp was not that it was a language, but that it was (or grew into) a software development environment.
"it was originally developed as a successor": There was no separate development. BBN LISP was a BBN project with ARPA funding; when some of the principals and users moved to Xerox PARC, ARPA funding continued for the same developers, who collaborated over the ARPANet.
Interlisp-10: When Interlisp to other machines, we distinguished between the versions with the suffix, so "Interlisp-10" ran on (some, not all) PDP-10 machines. In particular, it didn't run on the Tops 10 operating system, it ran under TENEX, an operating system for PDP-10s which had virtual memory (not all did). While Interlisp-10, Interlisp-VAX and Interlisp-D were language compatible (for the most part), there were some systems named "Interlisp" that were not.
Adoption:
Xerox 1100 (Dolphin) 1108 (Dandelion), 1186 (Dorado), 1100 (Dolphin). These were machines designed to run a bytecode interpreter, with the hardware designed with the focus on the byte codes for the Mesa programming language and the Pilot operating system. The development of Interlisp-D (and Smalltalk) did not influence the hardware design. The 1108 (Dandelion) was the same basic machine as the original Star workstation (with memory enhancements), the 1100 an early model in limited production
Interlisp had a (character terminal) Lisp-specific structure editor, debugging and analysis tools. The editing model differed from most systems in that one edited the actual Lisp structure of the program, and wrote out 'files' as save points. So the source code would be reformatted. Interlisp-D had graphic tools (window/mouse control, graphics system for drawing, visual structure editors) and the entire operating system (scheduler, file system, keyboard controller, network protocol stack) written in Interlisp.
Adaptations:
J Moore's "Interlisp Virtual Machine Specification", alas, has nothing to do with the byte coded virtual machine that was the underlying reason for machine portability. I think the best reference is probably
- L. Peter Deutsch. A LISP machine with very compact programs. In Proceedings of 3rd International Joint Conference on Artificial Intelligence, page 697, August 1973.
All Interlisp-D machines were microcoded to emulate a bytecode set that evolved only in small ways from the Deutsch design. It was possible to suspend a running image on one machine and resume it on another.
The 1987 port of Interlisp to SPARC started with a project at Fuji Xerox (in Japan) to code a byte code emulator, in C, which executed the same instruction set as the Interlisp-D machines. The work of the XAIS team in Palo Alto was to finish and tune the emulator and the necessary glue to connect the mouse, keyboard, file system, network, and so forth to the SunOS (Unix, XWindows) enviornment.
Masinter 06:04, 14 August 2006 (UTC) Larry Masinter 8/13/2006
- It seems that this property "The editing model differed from most systems in that one edited the actual Lisp structure of the program, and wrote out 'files' as save points" is pretty unique among the development environments. In all other development environments I know of (except maybe the recent Apple Swift "playground") the source code is stored in text files, and the text files are processed (compiled, loaded, and/or combined) to produce executable code. I think this would be worth mentioning in the article. Professor Tournesol (talk) 02:23, 5 March 2016 (UTC)