Re: guile and emacs and elisp, oh my!

[Andy Wingo]

Hi Tom,

On Wed 21 Apr 2010 00:36, Tom Tromey <address@hidden> writes:

> Andy> My name is Andy, and together with Ludovic Courtès I co-maintain Guile.
>
> Hi.  Thanks for writing this.

Thank you for writing this thoughtful reply!

> People have often discussed the desirability of one runtime to rule
> them all. This has even been attempted -- Gnome floated a proposal,
> there is Parrot, even the JVM and .NET are getting in on it.

Heh, perhaps we have oversold Guile a bit. It's true that Guile isn't
particularly well suited for implementing Haskell right now; nor perhaps
will it ever be.

But Elisp has a special place in Guile. We have thought a lot about how
to implement it well, and how to integrate it well with Scheme. We have
great support for threadsafe dynamic binding, good nil/null
interoperability, and if something needs changing in Guile to support
Elisp better, we'll do it.

So while it's true that we're currently getting a number of proposals to
implement other languages, and some code, Guile's first language will
still be Scheme, and the "other language" which it will best support
will be Elisp.

> A single language makes both reuse and debugging simpler. Multiple
> languages equals chaos.

You're certainly right that support for multiple languages complicates
reuse and debugging. I'm not sure I'd go so far as "chaos", though;
we'll see once we have a more real proposal.

Some other points:

> * The numeric tower.  Ok, this one is interesting!  But switching to
>   Guile doesn't actually push this into the one place where it is
>   needed: buffer sizes.  In fact, this is a sort of general problem with
>   the rebase -- from what I understand, it doesn't deeply touch the bits
>   that matter.

Heh, I think that's the essence of a refactor -- small,
correctness-preserving patches that eventually make shallow the deeper
changes. With an Emacs-on-Guile, one could make the buffer size a SCM
value, which would normally be a fixnum but could be a bignum. This
approach has advantages and disadvantages, and they would be considered
as part of that change, not as part of an Emacs-on-Guile change.

> * Continuations.  If you thought threads were going to wreak havoc, wait
>   until people call/cc from inside redisplay.

We have continuation barriers. Most likely we would, by default,
prohibit nonlocal reentry to Elisp functions.

> My experience with Emacs as a user and occasional developer is that
> elisp is fast enough for most tasks you'd actually want to write in
> elisp.  Sure, maybe parsing could use some low-level love (something
> better than parse-partial-sexp), or maybe regexps could use a speedup,
> but even those are marginal.  Even the GC doesn't seem so bad
> nowadays.

I would humbly submit that you have, over time, restricted the range of
programs that you would write in Elisp, to that set of programs that
Emacs' implementation of Elisp can deal with.

There are many programs that you just can't write in Elisp, linguistic
expressiveness aside: the implementation just isn't fast enough. It
shouldn't be that hard to thread my inbox ;-)


That said, I think that your concerns about what a Guile-implemented
Elisp would do to Emacs are important ones, and that our implementation
should take them into account. I still think that Guile and Emacs would
be a beautiful future, so we'll keep working on it; but our work should
not stall your own. Lexbind, native-threads, and emacs-on-guile do not
conflict in any important way, IMO.

Happy hacking,

Andy
-- 
http://wingolog.org/