Remember the Flux OS toolkit? [Re: Model]

[Dwight Hughes]

| From: BRIAN SPILSBURY <zhivago@iglou.com>

[ -- snip -- ]
 
| The python compiler might be useful, certainly. But flux has nothing
| to do with the proposed use of forth/some-tiny-lisp. Unless of course
| the flux toolkit is also a reflective language. :)

No, but forth is not reflective in the same sense lisp is either.
Of course, I am no forth expert, but the reflectivity I want for
the LispOS rather fundamentally depends on everything being an
object (implying tags) - a fixnum "knows" it's a fixnum. Wrapping
the Flux functionality in proper lisp objects should provide most
of the reflective behavior we are looking for, and we could 
progressively subsume the Flux functions into the LispOS environment
as desired.

| If flux handles devices well, then by all means, use it. The fact
| that flux can 'borrow' linux/bsd drivers is a major advantage.

Yes, it would be. The real gotcha seems to be video drivers, because
they are bound up in XFree86 and not the least modular (Flux could
be wrapped around an alien video driver but it has to be reasonably
modular, not spread all over the X package).

| Just at a glance over that url I can't see anything that mentions non-
| intel support, it would be nice to know if flux is going to limit
| itself to that platform, or if they just aren't shouting about it.

In their preliminary documentation they are careful to separate out
and mark the x86 specific portions (the grungy stuff -- like cpu 
identification, trap handling, page translation, x86 pc architecture
particulars (IRQs, PIC, keyboard,...), x86 memory models, ISA bus,
...). They specifically mention plans to port Flux to PA-RISC, PPC,
and probably DEC Alpha. They use it in their own OS research, so
they at least have an incentive to make it portable. The overall 
design appears quite well factored. I'm drooling to get hold of 
the new version's source code.

As to the tiny-lisp, I have nothing against it -- I just don't want
to launch a full kernel-lisp project on top of everything else we
are attempting. If we can break apart CMU-CL and create a cleaner
lower-level lisp for system use and have 80% of our work already done
for us it would be a vast help. Have you read Henry Baker's commentary
on a simpler, more efficient lisp? Look at "CritLisp.html" at
<ftp://server.netcom.com/pub/hb/hbaker/home.html>.

-- Dwight