Russ McManus <russell.mcmanus_at_gs.com> writes:
> I acknowledge the fact that moving to guile would be a short term
> loser. My assertion is that it would be a long term win to bring
> together these two user communities. I think it can be accomplished
> without too much pain.
I don't think it'd be a long term win either. Guile development has
been going on for years now and it's only marginally better than it
was when it first forked from SCM. In particular, there are lots of
basic things that people have been complaining about for years (e.g. -
slow startup time, the module system, lack of an object system, poor
TK interface) which still haven't been fixed.
> I would like to refine one of my comments, though. I think guile
> has a rate of growth significantly greater than STk. These things
> are impossible to measure, of course. But in my admittedly
> subjective view, I think that the growing number of important
> applications (some GNOME applications come to mind) that are using
> guile as an extension language is bringing along lots of new
> people.
>
> I think that because guile is the GNU project's scheme
> implementation, there will be many people who work on it and
> improve it, just because of this. My assertion is that it is a
> good idea for STk to take advantage of this future work.
This is all true. The only reason I'm currently doing anything with
guile is scwm. And the only reason scwm uses guile is because guile
is the "official" FSF scripting language. But, I still write my
scheme shell scripts in STk.
> You see, STk and Bigloo are both essentially the work of incredibly
> smart and hard working _individuals_. Making their work compatible
> with guile ensures that when these people move on to other interesting
> stuff, all their work will continue to be maintained, albeit by
> probably less bright, but still committed people.
Other people have worked with them. And Guile compatibility is
different from putting Guile under the hood. I'm all for as much
compatibility as possible amongst all the different scheme
implementations, but I don't think the solution is to put Guile inside
STk.
What sorts of compatibility are you looking for? Straight R4RS code
should run in either. If you add clos & the Tk classes to Guile then
modulo miscellaneous hacks (require vs use-modules, regexp
differences, etc) you should be able to run basic STk window stuff in
Guile. And there was at least a lot of talk from other scheme
implementers about being compatible with Guile's gh_ interface. I
don't see what sort of additional compatibility putting guile inside
of STk would have.
As for maintenance, if the original developers get bored & move onto
something else, there's always the possibility of the work being
picked up by others regardless of whether or not the internals are
Guile based and regardless of the degree of guile compatibility. And
given that STk's internals are a lot cleaner than Guile's, I'd expect
it'd be a lot easier to pick up the torch for STk as is than with
Guile inside.
--
Harvey J. Stein
BFM Financial Research
hjstein_at_bfr.co.il
Received on Mon Oct 05 1998 - 11:00:28 CEST