shivers@lambda.ai.mit.EDU (Olin Shivers) writes:
| I just don't have the time. I am already dreading the move to the next
| Scheme 48 release (but it will be *really* nice to pick up threads).
When you have fork, mmap, and pipe, not to mention call/cc, why do you
need yet another primative? It seems to run against scheme's
minimialist philosophy. Speaking for myself, I'm interested in scsh
only to the extent that it puts me close to the bare metal of unix,
and stays far away from trapping me inside of a virtual lisp machine.
Scheme48 seems to take the opposite view, alas.
| Tk is a terrible choice for a Scheme GUI. Osterhout, for reasons I
| cannot fathom, built tcl into the Tk functionality. This is
| brain-dead.
I disagree. It was a brilliant engineering decision, in the spirit of
Gabriel's worse-is-better paper. Tcl/Tk is simple, small, and highly
effective. Real closures for callbacks might be better, but it works
pretty darn well without them.
| However, I also think the whole callback/event-loop model is a poor
| substitute for concurrency. I would much prefer to assume threads
| and design a system like CML's eXene, or DEC SRC's Trestle (built on
| top of Modula-3).
A better example is Rob Pike's Acme window system, written in Alef (a
concurrent language). It's better because you can compare it to his
previous window system, 8.5 (written in C), which does approximately
the same job, but was more complex to implement (cf the Usenix paper
on Acme). In contrast, Trestle is much larger and more complex
(though not more useful) than Tk, which makes it hard to sell as a
better system.
The best part of Alef, by the way, is that it has separate constructs
for "tasks" (runtime system implemented, cooperatively scheduled
coroutines) and "procs" (OS implemented and scheduled processes).
That way there is no need for the runtime system to painfully and
inefficiently simulate OS features via kludges like nonblocking io.
|