Remember the Flux OS toolkit? [Re: Model]

[BRIAN SPILSBURY]

DH> | The python compiler might be useful, certainly. But flux has nothing
DH> | to do with the proposed use of forth/some-tiny-lisp. Unless of course
DH> | the flux toolkit is also a reflective language. :)
DH> 
DH> No, but forth is not reflective in the same sense lisp is either.
DH> Of course, I am no forth expert, but the reflectivity I want for
DH> the LispOS rather fundamentally depends on everything being an
DH> object (implying tags) - a fixnum "knows" it's a fixnum. Wrapping
DH> the Flux functionality in proper lisp objects should provide most
DH> of the reflective behavior we are looking for, and we could 
DH> progressively subsume the Flux functions into the LispOS environment
DH> as desired.

I'm not terribly keen on forth, but a lisp that small might suit?

DH> | If flux handles devices well, then by all means, use it. The fact
DH> | that flux can 'borrow' linux/bsd drivers is a major advantage.
DH> 
DH> Yes, it would be. The real gotcha seems to be video drivers, because
DH> they are bound up in XFree86 and not the least modular (Flux could
DH> be wrapped around an alien video driver but it has to be reasonably
DH> modular, not spread all over the X package).

The linux GGI project looks likely to solve this problem.

DH> ...). They specifically mention plans to port Flux to PA-RISC, PPC,
DH> and probably DEC Alpha. They use it in their own OS research, so
DH> they at least have an incentive to make it portable. The overall 
DH> design appears quite well factored. I'm drooling to get hold of 
DH> the new version's source code.

That's a major point in its favour.

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

No, but I will.

I have a feeling that a lisp will need to be built from the ground up.
If this can be avoided without breaking too much, that would be very cool.

Brian