>>>> "Olin" == Olin Shivers <shivers@lcs.mit.edu> writes:
Olin> How about punting S48 and moving to another Scheme platform? Wow, that
Olin> would be a ton of work -- we'd have to completely redo the I/O system,
Olin> the ff interface, and the whole top-level, for starters. We'd lose S48's
Olin> module system. And what system would we use?
Scheme 48 is, by far, the best choice for this. If you guys are
almost done with the static-heap stuff, then the biggest problem will
go away.
Another big win would be a generational garbage collector. Has anyone
tried plugging in Paul Wilson's collector, or the collector that's in
Elk? Shouldn't be too hard, since Scheme 48 provide the necessary
information for a precise collector.
Olin> - Guile?
Olin> Not all there. Doesn't have S48's module system. Pure interpreter;
Olin> no compiler at all. Not complete R4RS, I think.
Well, SCM is there, and that has a compiler. (It's called Hobbit.)
However, as many people have pointed out, SCM's execution model sucks
big-time. SCM (and, I assume, Guile) just does not run reliably for
very long, and that's not likely to change.
Also, it's development environment is minimal, and (due to the
execution model) not likely to improve.
Olin> - There's a nice system being developed by Paul Wilson and another guy
down
Olin> in Texas, I forget the name, That has potential.
It's RScheme, and the main guy there is Donovan Kolbly. It is nice,
but nowhere near the stability that Scheme 48 is at. It's still
changing. However, their new module system looks almost like a subset
of that of Scheme 48 :-)
Olin> - A port to Stalin would let you generate small, lean standalone binaries.
Olin> But Stalin is very alpha right now.
... and it's not Scheme. Probably won't ever be, with call/cc and what
not that Siskind is choosing to ignore.
Olin> - ??? Frankly, the main problem is that a lot of the heavy hitters
Olin> have moved on to ML. Sussman's group at MIT has *one* guy hacking
Olin> MIT Scheme.
Here are more choices:
Bigloo has pretty much the best compiler around, and also a working
FFI. However, its images are (despite Manuel Serrano's claims to the
contrary) also huge. Its interactive environment sucks. (There isn't
really one.) Debugging is via gdb, basically.
The same holds for Gambit (even bigger images), even though the
development environment is somewhat better than Bigloo's.
Elk doesn't have a module system, and the interpreter is SLOW. It
does have a nice, incremental collector, I believe.
Anyways, I believe scsh's advantages already by lightyears outweight
the problems associated with its memory usage. I'd been waiting for
just this for years, and I love it. Thanks, guys!
|