sperber(a)informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) writes:
>>>>> "Oscar" == Oscar Figueiredo
<Oscar.Figueiredo(a)di.epfl.ch> writes:
Oscar> I would completely sacrifice the technical advantages of Scheme
Oscar> or CL in favour of a common extension language used by other
Oscar> free software products, and currently that means Guile.
That simply is nonsense. Non-Guile Scheme implementations are at least
as common as extension languages as Guile itself. Fortunately, at the
*language* level, the Guile folks have since made sensible choices wrt
language design, reversing some of RMS's insane original ideas, and
basically making Guile a standard Scheme implementation.
OK, this is now very very Linux specific, but guile is at least used
in the GNOME project and hopefully will replace SIOD as an extension
language in GIMP.
I can't comment on the relative merits of guile (or malfunctions) when
it comes to the implementation of the Scheme standard or the inner
workings of that beast. But like Oscar, I really would like you all to
take into account some other things beside that hardcore, low level
stuff.
Just because guile has bindings to gtk that are actively maintained
and because of the fact that with the help of gimp and gnome a lot more
people get interested in scheme and develop new bindings for guile
makes it an option one really has to take into account, even IMHO if
there may be some other scheme implementation that's a little bit
better from a technical standpoint.
Of course this gtk stuff is only an exampe. But it shows that there's
now enough momentum in the guile user base that something like this
was actually DONE (as easy as it may be) whereas when I looked around
1 or 2 years ago I didn't find any really usuable binding to a GUI
toolkit besides some tk stuff.
The trick is to use a standard *language*, not a
"standard"
implementation. Then you can make decisions independent of the actual
substrate at hand. This is actually not so difficult with Guile as it
requires minimal cooperation from the C code. That very same property
makes it a problematic choice for an XEmacs substrate.
I don't understand that last sentence. Could you elaborate?
Regards,
jtl