Re: guile and emacs and elisp, oh my!

[Tom Tromey]

Andy> My name is Andy, and together with Ludovic Courtès I co-maintain Guile.

Hi.  Thanks for writing this.

I'm somewhat hesitant to write this response, since although I'm a
longtime Emacs-lover and random contributor, I'm not an Emacs developer
by any stretch.  So it isn't clear that I have standing to try to push a
particular big agenda.  Nevertheless, I care a lot about Emacs and I
found that my view on this topic has not been well-represented.

Andy> Guile can implement Emacs Lisp better than Emacs can.

Andy> No one will notice! Except that after a switch, Emacs would be faster,
Andy> more powerful, and have the ability to access all of Guile's facilities
Andy> -- the Scheme language, other languages implemented for Guile
Andy> (Javascript, Lua, ...), a proper ffi, dynamically loadable libraries, a
Andy> module system, the numeric tower (rationals, bignums, etc), Guile's
Andy> existing libraries, delimited continuations (!), fast bytevector access,
Andy> native threads, etc.

>From my perspective, many of these are either not interesting, or are
outright misfeatures.  Let me explain.

First, 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.

I think, contrariwise, that not only is this not desirable, it is
actively bad.  I think it is beneficial to a program like Emacs to have
a single extension language.  A single language makes both reuse and
debugging simpler.  Multiple languages equals chaos.

Furthermore, I think that secondary implementations of popular languages
(why even consider the unpopular ones?) are destined to always remain
second-class citizens.  There is plenty of evidence to support both
these assertions: the wretched state of Gnome scripting (brought on,
IMO, by its tower-of-babel approach), and the lessons of Jython, Iron
Python, et al.

For the other points:

* FFI, and dynamically loadable libraries.  This feature has come up and
  been rejected several times for Emacs.  Anyhow, as with all of these
  features, we don't need Guile to implement it -- and in fact that is
  an extremely roundabout way to add a simple feature.

* A module system.  I've seen this idea explicitly rejected by RMS.

* 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.

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

* Native threads.  There's an Emacs patch already.


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.

Instead, I see three areas for improvement.

1. Platform integration.  Some progress has been made here (dbus comes
   to mind).  My pet missing feature here is notification area support,
   but there are others (e.g., embedding).

2. Display model.  If you try to write, say, a decent presentation
   program in Emacs (let alone something truly complex like a browser),
   you quickly run into holes.

3. Blocking behavior.  I run nearly everything in Emacs, and anything
   that blocks is at least an annoyance, and can even wreak havoc
   (causing an irc timeout is no fun).  Emacs has decent-ish tools for
   handling this problem already, except for situations like Gnus --
   which is why I started working on threads.

So, what I would propose is that instead of putting a lot of energy into
rebasing Emacs on a different VM, put that same energy into providing
features that affect users.  If elisp doesn't quite suit, I propose
simply accepting that elisp is its own language, and not be constantly
looking at Scheme or CL as the promised land: just evolve elisp in situ,
say by merging lexbind or adding threads or whatever else there that is
both concrete and incremental.

Tom