
Closos: Specification of a Lisp operating system (2013) [pdf] - ska80
http://metamodular.com/closos.pdf
======
heisig
There is an active and growing group of hackers trying to make CLOSOS a
reality. The current progress can be viewed at [https://github.com/robert-
strandh/sicl](https://github.com/robert-strandh/sicl) (SICL is the Common Lisp
implementation that will be used for CLOSOS)

I am one of the contributors, so please don't hesitate to ask questions or
discuss ideas.

~~~
smabie
If you're starting from scratch, why not design a new Lisp? CL has never
struck me as a particularly inspired language, and neither has the kind of
code people write with it.

Or, if the idea is to leverage existing CL code, I'm sure with a little bit of
effort SBCL could run as a unikernel and provide a good base for the system.

Awhile ago there was a standalone Lisp implementation called Movitz. What are
your thoughts on that?

~~~
heisig
> why not design a new Lisp?

Hell no. Here is why:

1\. The Common Lisp standard is brilliant. If your new Lisp is designed by
anything less than a committee with people like Kent Pitman, Guy Steele, and
Richard P. Gabriel, chances are that you will end up with something worse.

2\. Common Lisp has one feature that people often forget about, but that is
crucial for an operating system - you can rely on the fact that the semantics
doesn't change. Lisp programs written in 1960 can usually be run on today's
Common Lisp without modification, so there is hope that programs written today
will still run properly even in centuries.

3\. Common Lisp has the most powerful object system and the most powerful
condition handling system. Both these features are invaluable for an operating
system. This is actually my main motivation for contributing to this project.
I want my programs to communicate via objects, and I want a system-wide
mechanism for recovering from errors without crashing or unwinding the stack.

4\. By relying on a very good existing language instead of reinventing this
wheel, there is a chance that CLOSOS will actually get finished.

> I'm sure with a little bit of effort SBCL could run as a unikernel and
> provide a good base for the system.

Probably. But to make CLOSOS actually useful, we need an abstraction for
having multiple first class global environments. And bolting that on top of
SBCL without breaking existing things is about as painful as a full rewrite.
The other big point is that SBCL values performance more than safety. But for
CLOSOS, safety is crucial.

> Movitz

We intend to borrow some ideas from Movitz. But since we managed to bootstrap
Common Lisp directly from Common Lisp, we hope that some things can be done
more elegantly. The other project that should be mentioned here is Mezzano
([https://github.com/froggey/Mezzano](https://github.com/froggey/Mezzano)). We
even borrow some code from Mezzano and are actively collaborating with its
author.

~~~
SeanLuke
> If your new Lisp is designed by anything less than a committee with people
> like Kent Pitman, Guy Steele, and Richard P. Gabriel, chances are that you
> will end up with something worse.

Nonsense. It's trivial to design a new Lisp better than this committee did,
regardless of how well a job they did, because hindsight is 20/20, and this is
50 years of hindsight. Step 1: take Common Lisp. Step 2: fix the obvious
design flaws and warts which have proven themselves irritating to everyone
over the years. And there are many, everything from a lack of standard
character set, to nods to ancient versions of Lisp (caddddr, association lists
and property lists, grotesque mistakes in EQUALP and EQUAL, lack of basic
functionality in hash tables and arrays -- broken equality testing, and
seriously, you have to write your own function to copy an array or hash table?
-- missing literals for standard data types, huge numbers of unfortunately
named symbols, on and on and on). Step 3: done.

~~~
lispm
while we are at it, let's also fix the obvious design flaws in C and
UNIX/LINUX, especially the huge number of unfortunately named functions and
commands.

~~~
SeanLuke
That's not the point. He said it wasn't possible to improve on the committee.
But of course it is.

But while we're on the subject: both C and UNIX are actively being updated and
improved even now. The Common Lisp standard hasn't changed in any significant
way since the 1980s. In Lisp everyone is just adopting ad hoc standards,
agreeing under the table that everyone should use a certain networking
package, threading mechanism, or Unicode standard for Lisp characters. That's
the worst of many possible ways to deal with the problem.

~~~
pjmlp
> But while we're on the subject: both C and UNIX are actively being updated
> and improved even now

Given the contents of ISO C17 and POSIX at Open Group it doesn't look like it.

Unless we have different understandings of improvement.

~~~
kazinator
What the ISO C people are doing can be called vandalism.

------
lachlan-sneff
I love thinking about ideas like this. A few years back, I wrote a kernel that
ran wasm similar to how Closos would run lisp. Webassembly is perhaps a bit
uninspired compared to lisp, but there are many advantages, although the
system cannot be dynamic in the same way that this would be.

I'd love to see these kinds of ideas revisited.

------
skulk
Interestingly enough, the four-step process that is presented in section 1.4
seems very similar to how Urbit is being built right now.

