UserLand & Kernel efforts: complementary, not opposite

[Fare Rideau]

There are been lots of comments lately
about what underlying kernel to choose for the LispOS project,
and how Lisp can take over parts of the services.

Let's (re)state my position:
0) There are two different kinds projects being discussed:
 the first one, say 'LispEnv, will try to provide Lisp interfaces
 for all user-visible functionality, ASAP,
 even though performance might not be great.
 The second one, say 'LispOS, would be a Lispy implementation
 of system layers, so as to achieve performance and consistency
 in a Lisp system.

1.1)
 LispEnv for obvious expediency reasons,
 should be implemented on top of an *already available* free OS.
 This currently means *BSD and/or Linux, though the situation may evolve
 (HURD has been named).
1.2)
 It is not essential to LispEnv to map Lisp-provided services back
 to the underlying Unixish kernel.
 It would be a nice hack, and Linux userfs and *BSD/HURD Mach servers
 show that it is quite possible.
 But beware the way it could spread the myth
 that Lisp is a slow language with unreliable latency,
 because we would have had to go through tons of filters
 while using some non-realtime GC.
 In any case, don't expect great performance from that.
1.3)
 An *essential* feature of LispEnv will be the ability
 to run on top of an existing system, so that users can still use
 their legacy software until LispEnv fully takes over.
 A full take over involves the translation/rewrite of lots of
 legacy software, which is unlikely until people are convinced,
 which in turns requires that an efficient runnable system
 be made available to them beforehand.
1.4)
 because LispEnv will have to communicate with programs on the
 underlying platforms, scsh-style system interfaces are needed;
 they are useful to build the LispEnv on top of them anyway.
1.5)
 A free*ix based LispEnv can make a pretty good cross-development
 platform for LispOS. It can be made available much faster,
 though it will be limited in many ways by the un*x braindamage below.

2.1)
 For various utility reasons, a Lispy kernel needs be built on
 top of as little Cish braindamage as possible:
 to achieve performance and consistency, clean semantics and robustness.
 For instance, Markus Daniels wondered about how we could
 provide reasonable system services without some kind of
 real-time GC; yet, real-time GC is costly,
 all the more if we have SMP and suches.
 Thus, we'd need multiple GC spaces, thus generic GC algorithms,
 thus modular/functorial programming, etc.
 Things that only using a Lisp language as a meta-language can bring.
2.2)
 A Lispy kernel could very well be used as the basis for better
 Unix emulators than a C kernel can ever be:
 multiple address spaces are useful for Lisp, and having them,
 it's not hard to add support for monolithic Cish black-box processes.
 Using Lispy wrappers, you could then define
 in a fine-grained way how services are provided to C programs,
 arbitrarily filter accesses to combine security while allowing useful work,
 simply provide accesses to services developed with the full power
 of a real programming language.
 By having smart C compilers taking advantage of the underlying system,
 with both high-level code transformations when possible
 and fine-grained low-level protection when not,
 we could even boost the performance of C programs!
2.3)
 An *essential* feature of LispOS is the performance and reliability
 it can bring with respect to system implementation,
 which is required to convince people
 to move to Lisp and high-level languages.
 Else, they will continue to write low-level C stuff,
 and we will continuously have to adapt our LispEnv
 to talk to interface to more C braindamage.
2.4)
 In the same way as Unix-based software can be ported to
 direct hardware access through Flux, improvements done for a purely Lispy
 environment can benefit back to the unix-based LispEnv,
 by adapting software to go through slow syscalls
 instead of fast direct access.
 BTW, debugging GC software on top of a free*ix is nicer than rebooting.
2.5)
 LispOS can make a pretty good underlying platform for LispEnv.
 It will free LispEnv from Cish braindamage, though it may take
 some time to implement.
 
== Fare' -- rideau@ens.fr -- Franc,ois-Rene' Rideau -- DDa(.ng-Vu~ Ba^n ==
Join the TUNES project for a computing system based on computing freedom !
                TUNES is a Useful, Not Expedient System
URL: "http://www.eleves.ens.fr:8080/home/rideau/Tunes/"