Re: Guile in Emacs

[Thomas Lord]

I really didn't mean to provoke a 20 message 
thread about what was, to me, just an idle 
thought and an interesting idea I wanted to share.

So, below I'll reply to Christian and I'll also 
indirectly reply to some of the other messages - 
but unless there is someone or are some people 
who, right away, want to start working on a Scheme-based
Emacs - there is probably not a lot to discuss.

If there *is* a non-empty set of people who want 
to work on it, they should speak up and we can try
to organize such an effort - the first step of which
would be to convene elsewhere besides this mailing 
list.

Otherwise, the whole thing is just a (to me) pretty
thought that I wanted to share with others who might
like to put in the back of their minds and contemplate
it a bit, until perhaps someday when there is an
obvious course of action to take.

On Wed, 2010-04-14 at 08:45 +0200, address@hidden wrote:
> I am personally mostly worried about Thomas' points about 
> getting scheme and emacs lisp to coexist. I just cannot
> see any evolution of emacs fly in the real world if it 
> involves a clean cut away from the existing base
> of emacs lisp libraries. How we would ever get 
> all developers and all users to back up such a move
> is beyond me ("all" used here in the sense
> of "enough to form a critical mass").


That's a legitimate concern but there are viable
solutions to the problem:

a) I'm *not* suggesting the idea of abandoning work
on the main development line of GNU Emacs.  I would
expect that work to continue and to continue to use
Emacs lisp.   There are so many GNU Emacs users and 
the program generates such a large amount of good
will for GNU that it seems to me very desirable to 
not "fix" what isn't broken.

b) I don't imagine that a Scheme-centric Emacs would
find itself with especially huge numbers of users in
its first few years of life.   I would *guess* that what
would happen is that many people would try out the 
first release just to see what the fuss was about, that 
a much smaller number would stick with it, and that a 
slightly smaller number of those initial users would become
contributing developers.   My guess is based on the assumption
that the first release is any good.

If things went well in the first few years, then 
the Scheme-based Emacs might start becoming seriously
popular.

c) Someone - I think it was Tom Tromey - observed
that Emacs Lisp is hardly something that is holding
Emacs back (so why change at all?, he asks).

I pretty much agree with that, at least in this sense:
If the only serious difference between GNU Emacs and
a new Scheme-based GNU Emacs were a change in extension
language - then there would be little point in bothering.

To succeed, a Scheme-based Emacs project would have to
produce an Emacs with features that users really enjoy
but that would be hard if not impossible to do in 
GNU Emacs with Emacs lisp.  (In contrast, just replacing 
the Emacs lisp interpreter with a version of Guile that
faithfully  implements Emacs Lisp can succeed
without needing to produce radically new features.)

What kind of features might a Scheme-based Emacs offer
that would be that important?  Some speculation:

Because Emacs Lisp support would be an explicit
non-goal, everyone's favorite lisp package would have
to be re-written (though, yes, often cribbing off
of the Emacs Lisp version).   Thus there would be 
opportunity (and a forcing function) to reconsider
countless "little annoying details" of those packages
and produce new versions with many improved details.

Because a Scheme engine *should* wind up being 
significantly faster, and because such radical 
changes to the C code would be needed anyway, there
is an opportunity to write more of the editor in
the extension language, and less in C.   In and 
of itself that doesn't help users.  In practice it 
can help users by making more of Emacs much easier
to modify and improve.   For example (and, yes, this
is a bit hand-wavy): if more of the display code
were in Scheme, there is a good chance that there 
would be more and fancier features and "nice touches"
in the display.

I think that most people would agree that Scheme
is a significantly more powerful language than Emacs
lisp in the sense that it is easier to write more
sophisticated programs in Scheme (with its closures, 
its fancy macro systems, and so forth).   This, again,
does not directly benefit users.   In practice it could
benefit users because in the same number of lines of
code (Scheme vs. Emacs Lisp) an extension package could
often provide more ambitious, fancier features.  I've
a few times mentioned the example SCSH (the Scheme shell)
and it's a fine example to use here:  a SCSH is not 
especially large or complicated.   SCSH presents a 
subprocess management interface that is light years ahead
of Emacs' and that would be rather painful to write in 
Emacs Lisp.  The interface to sub-processes is again
of no direct importance to users but what would benefit 
users are creative new applications enabled by the new 
interface.   That is, Scheme's more powerful environment
leads to subsystems like SCSH which leads to extension package
developers using sub-processes more often and in fancier
ways which - one would hope - leads to fancier, user-facing
extension language packages.

You get the idea, I hope.

Scheme isn't some magic bullet that, by its mere presence,
would advance Emacs into a bright new future.  It is a 
nicer, more comfortable extension language, more standard
than Emacs lisp, and affording more efficient implementations
than Emacs lisp could ever hope to afford - all details that
don't help users directly.

The stubborn decision to start fresh and  cannibalize
GNU Emacs to make a Scheme-based Emacs *could* be, in addition
to possibly being fun, a catalyst.  By forcing the rewrite or 
significant modification of large subsystems, it would force
a careful design review and updating - without the pressure
of being upwards compatible with Emacs lisp.   In that 
adapt / rewrite process, there is opportunity not just to go
after one or two new "killer features" - but rather to go after
many, many small but noticeable improvements all across the 
board.  And if more of the editor is written in the extension
language and the extension language is a more powerful language
with a faster implementation - then it *should* (no guarantees)
work out that within a few years the Scheme based version 
will have user-facing features that make people say "Wow.  The
old Emacs couldn't do that!"

-t