Flux toolkit as LispOS base

Dwight Hughes dhughes@intellinet.com
Fri, 2 May 1997 20:59:00 -0500

[snip - my original comment cut out]

|   OK, so now we have neither an OS nor a lisp implementation, since by
| definition, they all are warped by their initial design tradeoffs. So,
| how long before I can see the results of (car '(a b))? (I'm
| intentionally being a "bit" overly dramatic in my arguement.) When we
| find a piece of CMUCL that doesn't suit our purposes, we'll have to
| rip it out and put the better mouse trap in. No big deal! We have to
| start somewhere and I believe that starting from the ground up is a
| fatal mistake. By the time we get far enough along, the world will
| have passed us by again. The only way I can see us having any hope of
| "succeeding", is to follow the two pronged approach. The one prong
| starts writing today using using an available Common Lisp. They start
| writing all of the generic stuff that can be implemented for just
| about any CL implementation. Things like window systems, a generic
| networking system, and apps. The second prong looks into what it would
| take to implement OS services in Lisp. What they use as their basis is
| up to that group, whether it be Linux, *BSD, Flux, Hurd, or DOS. When
| they have an OS working along with the appropriate CL implementation,
| the apps guys port their parts over to it. Then we reexamine what we
| have and redo parts of it. And then do it again. And again. All the
| while building up a really neat system.
|   Mike McDonald
|   mikemac@engr.sgi.com

Well, true enough -- we will just have to rely on those amongst us that
know what
a true LispOS should do and be from their experience on LispMs. Hopefully
they can 
wave large red flags when we unthinkingly incorporate lame aspects of the
as they presently are.