Sorry that this is a bit off topic to two lists but i hate it when
good bug reports turn bad and run off into where they shouldn't....
To keep things relevant on at least one list, let me reiterate
an earlier request:
The GNU project is building Guile, an embeddable Scheme
interpreter. Guile has a unix systems programming environment
called goonix which is useful and lightweight, but which is
not able to run SCSH programs. We're looking for volunteers
to work on SCSH compatability for goonix.
Guile support for SCSH will mean that one day, all extensible
GNU programs, including GNU Emacs, will be able to run SCSH
programs.
Also, when you have one implementation, that is a proposed
standard. When you have two, that is an emerging standard.
Now for the non S48/SCSH part:
sperber@informatik.uni-tuebingen.de writes:
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.
Before spreading nasty rumours like this, please take the time to
produce a test case that illustrates the problem and submit a bug
report. I'm not aware of any problems in SCM or Guile that fit your
description.
I'm not sure what you mean by "execution model", but if you mean the
way objects are represented, SCM has an efficient and nicely
extensible model. If you mean the C-friendly way SCM uses the C stack
or passes parameters, yes, these facts are the result of different
trade-offs than the current S48, but they do not "suck".
But whether you mean the way objects are represented or the way
evaluation uses the C-stack, in neither case does this have any
obvious connection to the reliability of long-running processes. So
just what are you trying to say?
In the long run, i expect you'll see more convergence than divergence
on the available features of implementations so it is a bit false to
be treating different implementations as opposed, anyway.
Also, it's development environment is minimal, and (due to the
execution model) not likely to improve.
The next release will include early support for source-level, symbolic
debugging and a module system (and other new features to boot). The
Guile development environment is improving rapidly, right now, in
spite of what you say.
|