6. Lisp-based OSes
Symbolics and Lisp Machines built integrated hardware and software environments tuned to Lisp that were considered to be highly productive environments, with such merits as:
The OS is (save for little bits at the bottom, and even there, it's disputable...) written in the same high level language you use to write applications.
Since virtually everything on the system is represented by Lisp objects, tools for manipulating Lisp objects can manipulate pretty much everything on the system, including the OS.
The environments provided extensive integrated tool sets.
In C debuggers like gdb, you can typically trace back from a suitably instrumented object file to find the source code associated with it. Lisp Machines automatically knew where the source code was, for all code on the system.
A safe language means a reliable environment without the need to separate tasks out into their own separate memory spaces.
The "clearly separated process" model characteristic of Unix has potent merits when dealing with software that might be unreliable to the point of being unsafe, as is the case with code written in C or C++ , where an invalid pointer access can "take down the system." MS-DOS and its heirs are very unreliable in that sense, where just about any program bug can take the whole system down; "Blue Screen of Death" and the likes.
If the whole system is constructed and coded in Lisp, the system is as reliable as the Lisp environment. Typically this is quite safe, as once you get to the standards-compliant layers, they are quite reliable, and don't offer direct pointer access that would allow the system to self-destruct.
A result of the "shared environment" is that the complexity of the IPC schemes that proliferate on Unix and Windows simply evaporate.
CORBA is reasonably characteristic of how IPC protocols need to be constructed, it involves copying and marshalling arguments into input and output structures, along with all the joys of managing the memory consumed by those extra copies.
On a Lisp Machine, local communication simply requires a function call to a function in the same shared address space. There is no change of languages, no change of endianness, no need to serialize data, no need to make extra copies.
The business efforts in the Lisp area have failed; people still would like to have similar sorts of environments.
There are still some used Lisp Machines out there, and a company called Symbolics may be able to provide Genera software to run on a Compaq/Digital Alpha machine atop what used to be called OSF/1, although contact information is spotty, and pricing is reputedly quite hefty.
For some similar "flavor," Smalltalk environments reputedly provide similar integration between the programming language and the rest of the environment, and have inspired similarly fierce loyalty. NeXTStep was similarly inspiring, though it used "batch compiled" Objective-C which eliminates much of the "dynamic" flavor.
 | Some of the following links are probably dead; this nicely reflects the consideration that there has been a lot more talk than action, and many failed projects. |
 | The classic problem with the "LispOS Project" is that a large portion of the early effort would involve low level hardware hacking. The attraction of a "LispOS" is in having a powerful integrated environment; hacking on device drivers isn't attractive in that way. Furthermore, there have been several projects that built low level OS kernels; these kernels tend to be tightly tied to particular hardware configurations:
It's unlikely that a video card sold last year will continue to be available three years from now; that is quite a severe limitation on such efforts. |
Movitz: A Common Lisp OS development platform
The Movitz system aspires to be an implementation of ANSI Common Lisp that targets the ubiquitous x86 PC architecture "on the metal," running without any operating system.
cirCle will be a DFSG-free Linux-based Common Lisp development and deployment platform that integrates well with and enhances the Unix environment -- instead of aiming to replace it completely. Uses SBCL.
MzScheme atop Flux OSKit is probably one of the more "mature" options; it apparently took all of five hours to port MzScheme to run "atop bare metal" using OSKit.
It initially lacked support for filesystems and TCP, which means that it lacked the ability to save data or programs anywhere. Even with these lacks, probably still remains more functional than most of the other projects.
A Scheme system implemented as a patch to the Linux kernel . Interactivity is via the /dev/schemix device that presents a REPL to those given access.
This project is "dead." There is an archive of the mailing list at Tunes.org.
Now dead would-be outgrowth of LispOS effort. Uses Scheme as the exclusive language for kernel and drivers. Uses Unix models for filesystems, security.
NASOS - Not Another Scheme Operating System
Mildly radical Scheme-like OS for PC hardware.
Single address space; no "mode" separation
Persistent data - no filesystem
UI using schemed DHTML
A system that uses CAML as the underlying implementation language.
An operating system and operating environment written in Scheme atop a virtual machine which provides an abstraction layer between the hardware and the operating system, implying ease of porting between widely varying processors and other hardware.
Vapour is a Scheme -based OS design which lacks kernel, processes or filesystem. It allows for various multi-tasking systems (including pre-emptive) and allows for multiple users. The system is based around a single address space with a persistent store.
The discussion that characterizes GUIs as "active" and CLIs as "passive" provides some interesting observations as to why many computing systems are the way they are...
This describes an architecture for a Lisp CPU that ought to be able to be implemented on a FPGA.
The most realistic alternative, at present, seems to be the cCLan efforts, which are layering sets of libraries and tools atop the Common Lisp implementations available for Debian GNU/Linux.
The result of this is to take advantage of:
Ongoing development of hardware device drivers for Linux
Ongoing development of video drivers for XFree86
Ongoing development of graphics libraries such as GTK that run atop X
It may not be as tightly integrated as a "true LispOS," but it's more likely to be useful to people that need to write code now.
An interesting alternative would be to use Linux or one of the BSD OSes as a kernel, providing basic hardware support, and then for the init process to start up a Lisp program, which would ultimately mean that there wouldn't forcibly be any detectable Unix -like environment underneath.
That would provide the benefits of having the Linux/BSD folk develop hardware drivers, and yet leave you with a "completely Lisp" environment from the perspective of anything you'd see after the boot messages.
On the other hand, there's still a lot of user environment that would have to be implemented, so nobody has actually done this.
6.1. Links on the Original Lisp Machines
The Symbolics Virtual Lisp Machine Or Using The DEC Alpha As A Programmable Micro-engine
Lisp Lore : A Guide to Programming the Lisp Machine by Hank Bromley, Richard Lamson
If you want to buy a Lisp Machine, this describes some of the process. See also How to choose a good used Symbolics computer.
Vlee - Virtual Lisp Engine Emulator
A project to build a free software emulator for Lisp Machine processors.
Of course, this is of very limited use without paying thousands of dollars for a copy of Open Genera to run on it, and that is generally considered the main barrier to running a Lisp Machine these days...