This is excellent news, and also quite timely! I am working on a side project where I want to build an exokernel, and recently (earlier this week, in fact) I decided to use Pre-Scheme as a base for implementing this exokernel and other low-level libraries that handle functionality such as memory management. Eventually I want to be able to host a language like Common Lisp, or at the bare minimum, something like Self (which can be thought of as Smalltalk without classes; see https://selflanguage.org/) on top of Pre-Scheme. This is all part of explorations of how to build a modern OS inspired by the Lisp and Smalltalk environments of the 1980s but updated to address modern concerns such as security and multi-core processors.
I hope I'm not completely beside the point, but what you describe makes me think of the "malleable systems collective" people who I was reading more about recently:
I think there may be some synchronicity between the kinds of things being discussed on the forum section of that site and what you're attempting. Very cool project anyway, I hope it goes well!
Yes, this is exactly what I’m interested in, and building malleable systems is exactly why I’m interested in Lisp- and Smalltalk-style systems where metaprogramming and component-based design are infrastructure for enabling malleable software construction. Exokernels are also a nice complement since this aids in the swapping of even low-level OS components, since OS services are implemented as libraries on top of a tiny kernel that only handles hardware multiplexing and protection.
If I could nudge you a little further - as I think I'm almost following, but not quite - what's the difference between an exokernel and a vm? I mean, wouldn't you have to write a different exokernel for each architecture, with this set up?
Edit: reading more about exokernels - upon reflection, maybe I can better imagine how this kind of system could be very interesting for experimenting with what you describe. You'd effectively be drawing the boundaries the programs would cover much more broadly, so then maybe they could share more with each other?
I'm looking to use prescheme for low level code that needs more precise control where chibi scheme or guile isn't a good fit. I'm also hoping at some point that I have the time to write a borrow checker on top of prescheme, which might be a subset of prescheme but would still fit many use cases, so that it can be used instead of Rust. And also to create a transpilation step that creates optimizations, that would then ideally be proved. And then that way the borrow checked code with optimizations can be all transpiled by prescheme into C, and then tiny c compiler can compile it unoptimized into straightforward assembly. The goal would be to have verified code that can also be easily hand audited as well. LLMs just make all this stuff so much more possible because of how much faster we can iterate. Fun times for coding!
