Lisp-based computers developed at MIT and Xerox. The MIT line went commercial with SymbolicsMachine, LispMachinesIncorporated (LMI), and later TexasInstrumentsExplorer which subsumed LMI. Commodity hardware (MooresLaw) and better compiler techniques erased the cost/benefit ratio for a special purpose LispMachine.
Lisp Machine Manual version 1.4 Jan 1984, 1 PDF file per chapter, see directory http://www.bitsavers.org/pdf/mit/cadr/chinual_6thEd_Jan84/
"A Few Things I Know About Lisp Machines" -- extensive notes by someone who bought one post-2000 to see what they were all about. http://fare.tunes.org/LispM.html
"Lisp Machine" is a generic term. A Lisp Machine is a computer whose operating system and applications are written in Lisp. There were commercial vendors which offered such systems. Lisp Machines have been developed for AI programming in the mid 70s, because machines at that time were not powerful enough for complex AI software. It lead to the first workstations with megapixel screen, networking, large memory, multiple processes, mouse, graphical user interface, etc. Often Lisp Machines have hardware support for special facilities needed by Lisp - like Garbage Collection. The commercial Lisp Machines were setting standards for interactive programming environments.
Xerox' InterLisp D systems were one branch. Cool machines.
At roughly the same time, the MIT AI Lab created a Lisp machine for their AI research. These systems later were commercialized by companies such as Symbolics, Lisp Machines Inc. and Texas Instruments . These companies created their own machines.
With the "AiWinter", commercial Lisp Machines disappeared. Emulators of Xerox and Symbolics systems are still available.
Here's a whacky question: If there's so many bootable ForthLanguage flavors out there (EnthForth being the most memorable example) how come there aren't any bootable LispLanguage floppies? Having a Lisp run on bare hardware with shadow blocks would be a pretty sweet deal. -- MikeGodfrey (who wants to write one but wouldn't know where to start)
PS: Are there any LispLanguage implementations out there written using raw x86 BIOS calls? Finding a free, tiny one of those would be a great step toward making a lispy operating system.
PPS: Sorry if I've posted this on the wrong topic.
Whoa!! You are kidding, of course. Raw BIOS to build your OS on?!? Talk about pokey! There's a reason Windoze uses a Hardware Abstraction Layer to get some performance out of the underlying machine metalics.
The reason there are tons of ForthLanguage implementations is because Forth is easy to write. The standard for Forth is diminutive compared to CommonLisp. It's even simpler than Scheme's. It is entirely possible to implement a small Lisp-alike that runs on bare hardware. But, it will always be far more complex to write than the equivalent Forth language.
This is not to slam Lisp, however. CommonLisp is, to me, very fun to code in, even though I haven't done a whole lot of it yet.
First, what you say is true of CommonLisp, but there's nothing (well, nothing but lack of CopiousFreeTime) preventing someone from creating a Lisp dialect that can be as simple to implement as a simple Forth implementation. Such a dialect, however, would of necessity be close to the hardware, and wouldn't have garbage collection, types, and other things we tend to take for granted.
Second, when I was toying with RubyLanguage a few years ago, and had to deal with their system for dealing with different versions of Ruby (which advanced fast enough that it conflicted with Debian's package system), it occurred to me that language ecosystems are literally their own operating system environments--they just piggy-back on other systems. (Later I learned about PythonLanguage and Pip, which only reinforces my conclusions.) I have thought about how interesting it would be to write a LinuxKernel using CommonLisp...but that would involve writing a scheduler, functionality for disk access, ways to keep track of processes, etc (and would involve more of this CopiousFreeTime I keep hearing about). People like to bemoan the fact that there doesn't seem to be much research in developing Operating Systems, but there's a good reason this doesn't happen: developing a new operating system is hard! (That, and such bemoaning ignores the fact that research and new things happen more often than we realize; it's just hard to see, because it's in the background of our typical computer use.)
In any case, I don't think your observations on CommonLisp are a slam at all: when JohnMcCarthy started developing LispLanguage, he chose garbage collection, because he wanted to work with differential equations in an elegant manner. It is a choice that has advanced memory management in ways he couldn't have imagined at the time! And it is a choice that has benefited all of us greatly, even if it makes it more difficult (but not impossible) to write CommonLisp and friends "close to the metal".
Several LispMachine innovations have found their way into general-purpose microprocessors. One is software instruction emulation (where an unsupported machine instruction causes a processor exception; so that the OS can emulate the instruction in SW), see http://pt.withington.org/publications/LispM.html
It may be that LispMachinesAreComingBack
CategoryProgrammingLanguage (since the point was to support Lisp)