Hacker News new | past | comments | ask | show | jobs | submit login
Closos: Specification of a Lisp operating system (2013) [pdf] (metamodular.com)
90 points by ska80 35 days ago | hide | past | favorite | 22 comments



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 (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.


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?


> 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). We even borrow some code from Mezzano and are actively collaborating with its author.


Common Lisp was (per the name) designed to provide a migration path for a bunch of mutually incompatible LISP dialects that existed in the 1980s, but it wasn't fully compatible with any of them -- programs originally written for even MacLisp/ZetaLisp (the closest relatives) could take substantial work to port. See Pitman's post on Macsyma on this thread, for example: https://groups.google.com/forum/#!topic/comp.lang.lisp/fY92o...


> 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.


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.


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.


One can claim that C is best improved by replacing it with a new languages. See Rust, D, and others. Lisp, too. -> Clojure, Julia, Racket, ...

The 'step 1' 'take Common Lisp' is already hopeless, because there are few people interested in that for various reasons.

I don't think it's 'trivial' to fix a fading large niche language like Common Lisp, which was designed at a different time, with had much more design power back then. It's actually far from trivial.


> 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.


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


The CL Standard is also dated and crufty

A new design committee doesn't have to be the equal of the previous one when they have the benefit of both the original standard and literal decades of industry progress (cue grumpy Lisper "worse is better" allusion)


> The CL Standard is also dated and crufty

That was also my impression when I gave CL a shot a couple of months ago. Lots of strangely named functions, etc.


Dude, not even the people on the committee thought it was "brilliant." The language is ugly, wildly inconsistent, impossibly bloated, and encourages an antiquated and verbose style of code. There are reasonable reasons why it is the way it is, but only within the historical context.

I've written production CL code, and hated every second of it. Racket is much better designed, much more expressive, and encourages a better style of code.

There's a lot of reasons to use CL, but the brilliance (or rather lack thereof) of the language isn't one of them. CLOS is really the only good part of CL, but isn't even used in the base language!


> CLOS is really the only good part of CL, but isn't even used in the base language

Of course it is. The condition system for example is all CLOS. #'print-object works for and is specializable on everything. Every CLOS class is also a type, etc. etc.

If your complaint is that not enough CL functions are generic, I'd agree with you, but that's a much more specific complaint than "CLOS isn't used in the base language."

I do wish more functions were generic, but a big part of that problem is bootstrapping: In many ways you need CLOS to support CLOS. The fact that CL manages to bootstrap CLOS into itself even as much as it does is testament to the skill of its implementors.


> But to make CLOSOS actually useful, we need an abstraction for having multiple first class global environments.

This seems fine as a research concept but it wouldn't tempt me to use it.

IBM got on fine with CMS just being a single-user operating system.


First class global environments are not about having multiple users on the same machine. Their main purpose is isolation, sandboxing, and reproducibility.

Not every program should be able to modify the compiler, the kernel, or the garbage collector :)


Not the OP, but I would also use CL, it is an industry standard and there are endless libraries around.

Anything else is just yet another risk for the project ever reach any kind of long term adoption.

Clojure got this far only because it could ping back into the host libraries.


There is at least one bug in the Movitz compiler, It won't correctly compile a simple loop expression, I spent a fair bit of time trying to fix it.

I think it would be fairly easy to make SBCL run as a unikernel.

There is also Mezzano [1], it is a Lisp OS.

[1] https://github.com/froggey/Mezzano


If we're talking about Lisp OSs, there's also LOSAK https://news.ycombinator.com/item?id=16980640

Interim OS http://interim.mntmn.com/

Personally I'd be interested in a deterministic Lisp OS ie. Managed memory but no GC. Unfortunately that precludes CLOS but I'd imagine that many modules could ported over, depending on how far the language drifts.


> why not design a new Lisp?

Urbit.


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.


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




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: