In article <9511061454.AA23199@wavehh.hanse.de>,
Martin Cracauer <email@example.com> wrote:
>[I'm sending a copy of this message to Tom Lord, in case he is not on
>this list. Maybe you can point out mistakes I might have done?]
>Since the discussion goes on whether to base scsh on another Scheme
>implementation, let me ask, what exactly makes SCM a bad choice? I
>don't count the recent flame.
SCM is just kind of ugly, if I may express an (*entirely* personal) opinion.
It was not designed to be The Right Thing. It was something that
evolved from a one-person project, and it shows. For Scheme, it's a rather
Berkeley ("worse is better") implementation as opposed to an MIT
("diamond-like jewel") implementation. Scheme-48, on the other hand, is
definitely a diamond-like jewel. (That's not entirely a compliment.)
I'm stealing terminology from Dick Gabriel here. Apologies to everyone,
including Berkeley, MIT, and Dick. :-)
Both of these approaches have their merits and demerits. SCM is intended
to get to "market" fast, to compete with the evil TCL hordes. It's Scheme,
and it works.
Scheme-48 is intended to be the Right Thing, as conceived by Richard Kelsey
and Jonathan Rees. It is still, after many years, "unfinished" for practical
purposes. (E.g., footprint and speed problems.)
I worked with Scheme-48 many years ago when doing my dissertation. I
took a third-party implementation of the VM, written in C, and hacked
a state-of-the art generational copying GC into it. Then the VM changed
out from under me, and since I wasn't a PreScheme savant, I lost big.
It has proven faster to implement our own, higher-performance Scheme
system than to wait for Scheme-48 to be both good and open for the
kinds of research we like to do.
RScheme was partly designed in response to Scheme-48. I learned a hell
of a lot from Scheme-48, for which I am eternally indebted to Richard
and Jonathan. (THANKS, GUYS!) You should---NOT---have seen the Scheme
system I started before I learned the innards of Scheme-48 and learned
One of the negative things I learned, though, was that bytecode interpreters
really suck as a primary execution model---though they have great advantages
as a secondary code generation strategy---and are not the Right Thing.
You really want to compile to some kind of native code for any kind of
real performance. You also want your abstract machine to be more powerful
(low-level and compiler-oriented) than Scheme-48's, or it will be a bitch
to ever get excellent performance out of it. (And you don't want the
virtual machine to be implemented in a nonportable, weird language.)
(Not that we've gotten excellent performance out of RScheme yet. Only about
4 times faster than interpreted SCM, which isn't much, considering that we
compile to native via C; we must do better, and I think we *will* do much
better. Our bytecode performance is only comparable to SCM.)
Compiling to C is a huge win price/performance and time-to-market-wise.
(By "price" I mean the price to develop a system that you can give away
as we do, or sell.) C is the only abstract machine that has an
implementation on every important modern computer system, because SPECmarks
rule the market.
I also came to the conclusion that stack-based models aren't great, and
that register-based models are better. We've yet to prove this, because
we haven't tweaked our compiler enough to see what its fundamental
performance limits are.
A year or so ago, I proposed to the GNU project that they use RScheme
as the basis for Guile, since I (and others) believe that its design
is fundamentally superior to the design of SCM. (This is not to fault
Aubrey Jaffer, who has done excellent work and is a great boon to the
Scheme community in general. But SCM evolved before the Guile project.)
In my view, RScheme was designed from the start to be what SCM "should
have been" if it had been designed to be Guile. Unfortunately, it wasn't
started soon enough, though we seem to be catching up.
Here's the biggest reason why the GNU people didn't use Scheme-48 or
RScheme: neither one ready. SCM was. It was running, and it was robust,
and it had a small footprint suitable for an extension language.
This is not a factor to be taken lightly. We had to admit that RScheme
wasn't ready yet, in that it was in flux and flaky. Scheme-48 was more
stable, but it was slow and fat. (It still is.)
>As you know, SCM is the base of guile and cygnus recently announced
>their plans to hire two additional full-time people for guile work,
>one documentation writer and one coder. Those are resources that can
>be very useful for fixing things that are time-consuming and boring.
>Guile intents to be a collection of a number of useful
>libraries. Making scsh such a library would mean:
>- scsh would be distributed to a much wider audience.
>- this audience, having installed guile for other reason, would have
> scsh available on their system. That makes evaluating scsh much
>- scsh could use all the libraries. Imagine what you could do with the
> Tk GUI toolkit in scsh "shell" script.
>- Maybe scsh could profit from additional syntaxes planned for
> Guile when going towards some form of elegant syntax for interactive
> shell work.
>- I'm sure the guile people will implement something like scsh
> sooner or later, limiting scsh's audience further.
>- Guile is probably the Scheme implementation with the best chances to
> get a fancy development environment in the near future.
>All these are have to do with availiable resources and I wonder if
>these don't outweight technical problems that the current
>implementation of SCM might have.
I think it's a good idea to consider scsh.
It's also a good idea to document Guile. We proposed to evolve RScheme
toward Guile compatibility, by default, but we haven't heard enough about
Guile to know what to evolve toward. (We also haven't been in the loop
of the design process, and as far as I know other experienced Scheme
implementors have not either. I could be wrong about this.)
>From the RScheme project's point of view, it appears that we have to
wait until an implementation comes out, reverse-engineer a spec, and
reimplement it. This is a major pain in the ass. We have given up on
compatibility for the time being. We'll do what we think is the Right
Thing, and hope it's powerful enough to subsume Guile. (This is not hard,
in most places, because Guile seems to be fairly straightforwardly
implemented. Unfortunately, though, Guile also seems to lack nice internal
abstractions, and documentation just means exposing the innards.)
This concerns me. I think Guile could be very important, and could be
the kernel around which Scheme rallies. But maybe not if it's ugly, and
maybe not if it's defined by an implementation, and maybe not if it's done
with too little consideration for the Scheme community's sensibilities.
Don't get me wrong here---looking at the Scheme "community", I understand
the decision to strike out and just DO SOMETHING. Scheme has not advanced
fast enough not to fall by the wayside. The Guile group is justified
in just "going for it" rather than waiting for Scheme to become a Real
Language. Likewise, I understand the decision to grab an existing
implementation and just use it.
I hope the Guile project will consider alternative paths, though, in
1. Consider phasing in a different basic implementation, one that is
cleaner and more forward-looking, such as RScheme (or Gambit or
Bigloo or whatever looks best soon),
2. try to design things well and carefully, and document them so
that it's not hard for others to be compatible.
>Of course, doing so would place major parts of scsh under the GPL. Is
>that a problem?
My understanding was the Guile was not GPL'd, but was distributed under
a more liberal TCL-like license. RScheme is distributed under a similar
liberal license. (I.e., you can use it in commercial products.)
>I'm new to this list, so please be gentle. But I really appreciate any
>founded opinion on why SCM is technically bad, in any form :-)
I wouldn't say SCM is technically bad. It's just not what I want. I
naturally prefer the system I (with Donovan Kolbly) designed.
My favorite reasons to prefer RScheme:
1. Ugly tagging scheme. Too many tag values, not designed for
2. Too committed to conservateive stack scanning for the GC.
3. Not really designed with a compiler in mind.
4. No clear internal abstractions of primitive operations. (This
goes along with 3, and also with 2, and makes it harder to
implement things that do tricks with pointers, such as swizzling.)
>P.S. Is there an archive of this list available?
>Martin Cracauer <firstname.lastname@example.org>
| Paul R. Wilson, Comp. Sci. Dept., U of Texas @ Austin (email@example.com)
| Papers on memory allocators, garbage collection, memory hierarchies,
| persistence and Scheme interpreters and compilers available via ftp from
| ftp.cs.utexas.edu, in pub/garbage (or http://www.cs.utexas.edu/users/wilson/)