Flux toolkit as LispOS base

[Marcus G. Daniels]

TP> Just to name an example, it still leaves you with the pipe model
TP> of interprocess communication: everything is a stream of bytes.
TP> Ripping out pipes and replacing them with some more sophisticated
TP> object-passing system isn't going to be so easy.  You also still
TP> have Unix signals, whereas a more fundamentally derived Lisp
TP> system might want to implement asynchronous traps with exceptions.

KM> But it's easy, and that's the point!  
KM> Silk programs communicate by sharing persistent objects.
KM> You can "fake" this today, by having all programs run in the same
KM> address space and share transient objects.

And if it isn't possible to replace components one by one with Lisp
alternatives, the LispOS cause is probably lost, because integration
with the Real World is absolutely necessary in order to get people to
adopt the system.

Implementing some things in terms of "streams of bytes" isn't
something I see as particuarly insidious.  For example, although ILU
missing Lispy features, I don't consider the Common Lisp interface
to ILU as ruined by C or Unix.