Re: Guile in Emacs

[Thomas Lord]

We risk drifting into the topic of "general strategies
for GNU" and away from "what could / should(?) Emacs
do" so let's not make a long discussion of it but:

On Tue, 2010-04-13 at 13:44 +0100, Bruce Stephens wrote:

> I wonder.  Looking at the list of Guile applications doesn't give me the
> impression of a guile-using GNU ecosystem just waiting for Emacs to
> join.

Sure.  The optimist's version of that observation
is that, hey, it's a blank slate: pure opportunity,
no legacy "baggage".  The sky's the limit.


> Wouldn't it be about as good (and probably less work), to give up on the
> guile idea and evolve emacs lisp (with Miles's lexical-bind changes, and
> (one hopes) multithreading, and maybe other things)?

I dunno.  Maybe.  I'd guess that, no, that's not a 
good strategy.   Four reasons come quickly to mind:

1) There are many more materials out there that teach
Scheme than teach a novel spin-off of Emacs Lisp.

2) There are many and will continue to be many
implementations of Scheme.  Some of these implementations
are the product of pretty intense R&D.   No, they aren't
all 100% compatible with one another - far from it - but
it is easier to start with any one of those and make it
more like the others than to, say, build better and alternative
implementations of Emacs Lisp.

3) Scheme has features that we know make it a pretty
good "multi-paradigm" language.   Features like Scheme's
macro systems, proper safe-for-space tail recursion,
etc. are pretty good to have.   It would be easier to just
use those existing features than to try to retrofit them
into Emacs Lisp.

4) Using Scheme, you can can leverage third party 
Scheme code.  There isn't a huge amount worth using
but there is a decent amount.  There are the SRFIs.
There is SCSH (the Scheme shell).

For a long-term investment, I'd put my money on Scheme
rather than an ad hoc offspring of Emacs Lisp.