

Closos: Imaginary Lisp OS - alrex021
http://bywicket.com/users/mikel/weblog/fbc2a/Closos.html

======
rbanffy
It's a wonderful idea.

If the MIT folks decided, today, to build a Lisp Machine, what would it look
like? What would future LMI and Symbolics turn into? How would that affect the
way we work?

And, while I am at it, what would a Debian GNU/Plan9 or a Ubuntu Plan9 look
like?

Would it be more successful if it looked more like a traditional Unix desktop
and exposed its sophisticated internals only to the power-user?

~~~
arethuza
A lot of applications today end up running on top of at least two layers of
virtualization - VMWare ESX/HyperV providing guest operating system instances
that then run the application based on something like the JVM or CLR.

I've wondered whether these two virtualization layers could be combined so
that you end up with a hardware-abstracton VM sitting right on top of the
metal and then you write the bulk of your OS on top of that (which could then
be based on something far removed from the hardware, like your CLOSOS).

NB I'm a huge fan of CLOS - but factoring in security to a shared CLOS like
environment would presumably be a nightmare. Maybe each OS level application
could morph into something more like a guest OS in a virtualized
environment...

------
thisrod
I think the concept of a lisp OS is a type error. Lisp has interpreters and
runtime systems, that run on operating systems. However, Plan 9 suggests ways
those interpreters could be better structured.

The core features of Plan 9 are that programs interact with their environment
by naming things, that names refer to whatever programs or their interpreters
mount on them, and that interpreters have a protocol to pass the buck to
another progam when they don't know what a name means. To me, those ideas
suggest a sequence of titles such as "Mount: the ultimate module system" and
"Mount by wire protocol: the ultimate foreign function interface". I don't
know what papers would have those titles.

The idea would be to decouple lisp interpreters and dialects from lisp
libraries. If you could mount any functions that your favorite interpreter
lacked, then diversity would cause smaller problems. You could write a single
Apache plugin in C that spoke the apply protocol, and suddenly every lisp
would support the mechanics of HTTP. Or, the web parts of your program could
run in Arc on a PC, and mount procedures written in common lisp and running on
a supercomputer for the number crunching. The various lisps might have enough
in common to make those things work.

------
phren0logy
Isn't there already a "lisp OS" called emacs?

 _ducks flying debris_

~~~
rbanffy
I guess one could write an acme mode for emacs ;-)

------
zeynel1
"One lesson of Plan 9 is that the right organizing metaphor is extremely
powerful."

This sounds like a fundamental idea. Can anyone offer some more real life
examples?

