From: email@example.com (Scott Schwartz)
Date: 22 Dec 1995 23:34:02 GMT
| 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.
Scheme48 does, as you say, take the opposite view. Kelsey doesn't want to make
OS-dependent design decisions. This is good and bad. It's good because it
helps make S48 more portable. It's bad because one it means providing only the
weakest, most generic access to the machine.
That's the difference between S48 and scsh. Scsh gives you Unix in all its
sordid glory. This is bad and good. It's *extremely* limiting, but also
means you can really get some work done.
Neither solution is a global optimum. As I've said before, it'd be nice to
see how powerful an OS interface you could design that ran on Win32, Posix,
and Copeland. I regard carrying scsh all the way through for Unix as a
first step in this task. I've learned a lot about OS interfaces and Unix
from doing it. The next step would be to study Win32. I can't claim this
is on my todo list.
| Tk is a terrible choice for a Scheme GUI. Osterhout, for reasons I
| cannot fathom, built tcl into the Tk functionality. This is
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.
I make Bill the cat sounds in your general direction. Tk is all of
those good things you say it is: simple, small, effective. But it could
have been just as simple, small, and effective had Osterhout made
tk a tcl-independent subroutine library, and then provided a tcl binding
for its interface. And it would have been much more useful as a general