
LispOS: Specification of a Lisp operating system (2013) [pdf] - molteanu
http://metamodular.com/lispos.pdf
======
drmeister
A growing group of us are implementing Clasp ([https://github.com/clasp-
developers/clasp](https://github.com/clasp-developers/clasp)) - a new Common
Lisp that uses Robert Strandh's Cleavir compiler, interoperates with C++ and
uses LLVM as the backend. Clasp is the foundation of Cando - a programming
environment for the development of molecular devices
([https://www.youtube.com/watch?v=mbdXeRBbgDM&feature=youtu.be](https://www.youtube.com/watch?v=mbdXeRBbgDM&feature=youtu.be)).
Robert Strandh is an exceptionally clear thinker and a fantastic programmer. I
can't count the times that Robert has implemented changes to the Cleavir
compiler source code and without him being able to test it (long story) passed
it to me and it ran flawlessly in Clasp. I implemented his fast generic
function solution within Clasp based on another of his papers
([http://metamodular.com/generic-dispatch.pdf](http://metamodular.com/generic-
dispatch.pdf)). Edit: Basically - if Robert writes it up in a paper - I want
to have the implementation.

Once we develop molecular robots - they are going to implement LispOS. :-)

------
omaranto
Oh, this by Robert Strandh, whose also writing SICL, a very cool, modular
implementation of Common Lisp in Common Lisp for bootstrapping. The idea is
that other implementations of Common Lisp in Common Lisp can take modules from
SICL. Already Christian Schafmeister's Clasp, another very interesting
implementation of Common Lisp (using LLVM and made for easy interop with C++)
uses parts of SICL, particularly the compilation framework Cleavir.

------
kyberias
From Chapter 1.4:

"The most important aspect of a Lisp operating system is not that all the code
be written in Lisp, but rather to present a Lisp-like interface between users
and the system and between applications and the system."

~~~
ssivark
If this is too be run on regular CPUs, since assembly programming is
imperative, won't there necessarily be non-Lisp-like code underneath, with
(hopefully) Lisp-like interfaces?

~~~
mruts
Classical Lisp was never really big on FP. Scheme is the variant in which FP
is more emphasized.

If you look at the code of OpenGenera, it’s mostly OO/imperative.

Though modern FP has significantly diverged from Lisp and it’s roots. Things
like static-typing, higher kinded types, etc etc

~~~
ssivark
To cut to the chase, is the takeaway claim that it's easy+performant to write
low level code in lisp? Out of curiosity, what would be good examples along
these lines? Thanks!

~~~
mruts
Check out [https://github.com/mietek/mit-cadr-system-
software](https://github.com/mietek/mit-cadr-system-software) Itss a tape dump
of the CADR system. Also you could check out OpenGenera, but it's not
(legally) available.

If you want modern examples, check out SBCL, the Common Lisp compiler
[https://github.com/sbcl/sbcl](https://github.com/sbcl/sbcl)

While a Scheme and not a Lisp, you can check out Gambit Scheme.
[https://github.com/gambit/gambit](https://github.com/gambit/gambit)

It's written in a functional style and compiles Scheme to C. The generated
code is really fast.

As an aside, there really should be no difference in performance between a
loop and a tail recursive call, assuming the compiler does TCO. So if that's
your definition of "functional", then it should have the same performance as
any "imperative" language.

------
iovrthoughtthis
I feel like the concept of lisp speaks to the part of me searching for simple,
holistic consistency. The same part of me that wants to implement the general
solution rather than the specific solution.

While I've grown a lot since those times when I would act on those thoughts
more I still get a lot of satisfaction from moments when I get to exercise
that part of me.

I would love to get involved with a project that is doing this. Are there any
others other than Mezzano?

------
abrax3141
[https://www.researchgate.net/publication/228351943_KnowOS_Th...](https://www.researchgate.net/publication/228351943_KnowOS_The_re_birth_of_the_knowledge_operating_system)

------
openfuture
I feel GuixSD is approaching this with Shepherd for init and Guix for package
management, Emacs and then some lisp wm?

------
d33
Was it ever implemented? Are there any usable (at least working in a VM with
networking) Lisp OSes out there?

~~~
ThinkBeat
Emacs :) A great operating system that needs an editor

~~~
Y_Y
This is an old joke, but a good one. Modern emacs has full colour graphics,a
window manager, a decent browser, evil makes editing possible for people with
ten fingers or less...

I (and many others) have been thinking about a system that boots to Emacs.
With the guile backend we might get enough speed to make it tolerable
fulltime.

The only thing missing (and I bet somebody has done this too) is a way to run
graphical ELF binaries with an embedded X/Wayland type thing.

~~~
alecigne
I use EXWM and it's basically EmacsOS.

~~~
globuous
Wooow !! I've been looking for this for years !! Currently using emacs + dwm.
I'll check out EXWM see if it can beat my current workflow :D

------
mimixco
From what I've read about Lisp machines like the Symbolics workstation or the
TI Explorer, one of the huge advantages of a Lisp OS is that all of the OS
functions are written in Lisp itself and are open source. Think of the ease of
interfacing with something like that vs dealing with the various software
brick walls and APIs you need to program in Windows. Want to know what the OS
is doing? Read the code. Want to debug something? Step into the OS itself.
Don't like your UI? Change it.

Lisp machines were always meant as workstations for programmers rather than
office users, and it was expected that they would want to hack every part of
the OS. That's pretty cool.

~~~
lispm
> Lisp machines were always meant as workstations for programmers rather than
> office users

Lisp Machine were initially developed inhouse (MIT, Xerox, BBN, ...) as
workstations for AI software development. They were also used for early non-AI
stuff, since they were object-oriented, had a GUI and were hardware
extensible.

The commercialization by Xerox, Symbolics, LMI, TI, and some others did also
address developers initially - but at some point in time the machines were
also deployed in machine rooms in production as servers or as systems for 'end
users'. That happened once interesting software was developed and need to
deploy - remember that the early stuff was all financed by the military and
they also deployed some of the stuff which got developed - some really fancy
stuff like battle simulation systems, where the Lisp Machine created and
maintained virtual worlds for training soldiers.

For example Symbolics sold a whole range of machines and software to
graphics&animation. A lot of the early computer graphics you saw on TV were
done on Symbolics machines. The users then were graphics artists, animators,
3d graphics experts, ... Thus the user interfaces and the machines themselves
needed to be made end-user friendly. A bunch of the machines were deployed in
production. For example Swissair used a software running on TI explorers to
optimize the sales of flight tickets - it was interfaced to their booking
software running on mainframes. It was extremely difficult to port that
software away from the TI Explorer and for many years they bought all
remaining used TI Explorers all around the globe to keep their system running
- long after TI has exited that business. There are a bunch of other users of
Lisp machines who were not programmers - for example in military.

It was also thought that Lisp Machines could run as embedded systems in weapon
systems (autonomous submarines, cruise missiles, ...), onboard a space
station, and in other settings - that was then not really happening. But for
example AT&T Lucent had a Symbolics designed Lisp Machine board for a rack-
mounted installation and they were switching nodes in a telephony network
switch. Thus the operating system of that Lisp Machine was stripped down for
use in embedded systems (called Minima).

~~~
mimixco
Good info here but Lisp has not historically been "object oriented." The CLOS
(Common Lisp Object System) was added later as an abstraction layer over more
fundamental Lisp concepts.

One of the most beautiful things about Lisp is that has neither modules,
objects, routines, callbacks, variable types, or any of the other cruft of
more recent languages. (It is the second oldest computer language.) But -- it
can provide all of those things _if_ the programmer wants them.

~~~
kazinator
It depends on what you mean by "object-oriented".

A Lisp with no formal OOP system still has objects: conses, strings, symbols.
These are nicely abstracted: they are defined by operations which construct,
access and otherwise manipulate them. These entities have an identity (which
we can test with _eq_ ) and carry a type. They can move around freely in the
program.

There is genericity without OOP: features like _car_ working not only on a
_cons_ cell, but also on the _nil_ object. Or _length_ calculating the length
of a vector, string or list.

All of this stands in contrast to a procedural paradigm in which there are
just storage locations operated on by code, having whatever type the code
believes them to have. (Algol 68, Fortran 66, C).

~~~
mimixco
I think OOPS as a paradigm is pretty well defined without my laying it out.
The facts are that Lisp did not have OOPS at the beginning but it's easy to
add, and that's one of the greatest strengths of Lisp as a programming
language. You can build any programming concepts from modern languages that
you want -- but you aren't _constrained_ by any of them.

------
akkartik
The historical reason given right at the start for the design of processes
seems wrong. What do others think?

~~~
timClicks
Sounds plausible to me. Adding virtual memory to get around a constraint of
limited physical hardware & lack of MMU sounds like a software abstraction,
which is what software engineers building an operating system are likely to
want to build.

~~~
akkartik
Your reasoning is valid, but it only explains virtual memory, not processes.
Processes are primarily a means of isolation. If anything they're liable to
_increase_ memory usage, because the lookup tables need to be saved somewhere.

See also my comment at
[https://news.ycombinator.com/item?id=19121443#19129363](https://news.ycombinator.com/item?id=19121443#19129363)

