Closos: Specification of a Lisp operating system (2013) [pdf]
metamodular.com
metamodular.com
I am one of the contributors, so please don't hesitate to ask questions or discuss ideas.
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?
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.
I think it would be fairly easy to make SBCL run as a unikernel.
There is also Mezzano [1], it is a Lisp OS.
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.
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.
Not every program should be able to modify the compiler, the kernel, or the garbage collector :)
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)
That was also my impression when I gave CL a shot a couple of months ago. Lots of strangely named functions, etc.
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.
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.
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.
Given the contents of ISO C17 and POSIX at Open Group it doesn't look like it.
Unless we have different understandings of improvement.
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!
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.
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.
Urbit.
I'd love to see these kinds of ideas revisited.