Re: Guile emacs thread (again)

[Robin Templeton <robin@terpri.org>]

Christopher Allan Webber <cwebber@dustycloud.org> writes:

> Hello!  It's been a while since the topic has come up on this list, but
> many of us are interested in it, and maybe some developers don't know,
> and I hadn't seen any conversations on the list despite recent progress.
>
> Anyway, it seems that BT Templeton's emacs on guile project this summer
> has gone fairly well, and it looks like almost everything runs.  See:
>   http://www.emacswiki.org/emacs/GuileEmacs
>
> I remember reading Andy Wingo's email about this a few years ago,
> "guile and emacs and elisp, oh my!":
>   https://lists.gnu.org/archive/html/emacs-devel/2010-04/msg00665.html
>
> I found it very inspiring.  It seems those things are fairly close.
>
> So this email is partly a:
>  - What now?  What's the chance of work towards guilemacs moving over to
>    an official emacs git branch, and that port happening, anytime soon?
>  - Is anyone running it?  How's it going for you?
>
> (I'm mid-compile of the guile wip branch right now...!)
>  - Chris

First, I'd like to clarify some things about Guile-Emacs for those just
tuning in. The goal of the project is to create a better implementation
of Elisp than Emacs provides -- providing full compatibility with
existing Elisp packages -- and to use that as Emacs's Lisp
implementation. That implementation is Guile-Elisp, a compiler targeting
the Guile VM, and Guile-Emacs is the variant of Emacs based on this
compiler.

What will this mean for Emacs? Better performance and new language
features. Guile provides a fast virtual machine and a sophisticated
compiler infrastructure, and the Guile VM outperforms the Elisp bytecode
interpreter on a variety of benchmarks. Guile natively provides many
features from Scheme and Common Lisp not present in Elisp, including a
full numeric tower, structure types, CLOS-based object orientation, a
foreign function interface, delimited continuations, a module system,
hygienic macros, multiple values, and threads.

It will not mean that Elisp programs will need to be rewritten in
Scheme, or even that Emacs will necessarily support extensions written
in Scheme (much less JavaScript!). Interaction with other languages is a
possibility, but the exact relationship between Elisp and other
languages will be up to the Emacs maintainers and community. Elisp is
here to stay; Guile-Emacs will not remove Elisp but will instead enable
and accelerate its evolution.

The fifth Guile-Emacs Summer of Code project has concluded successfully.
Thanks to Andy Wingo for supervising my work, and to Google for funding
the project. This summer is when everything really came together. The
project previously had two independent components developed in parallel:
Guile-Elisp and Guile-Emacs. Guile-Emacs used libguile for garbage
collection and object representation, but retained the original
interpreter and bytecode interpreter and did not, initially, use the
compiler at all. The two components have been successfully united. Emacs
now compiles all Elisp code using Guile-Elisp, and all programs are
executed on the Guile VM. The old interpreter and bytecode interpreter
have been excised entirely. Guile-Emacs loads, compiles and executes the
programs included in Emacs by default, plus Gnus, Org-Mode, and more.

Additionally, Guile-Emacs was rebased onto a recent development version
of Emacs. Guile-Elisp was ported to guile master, which will become
Guile 2.2 and includes a new and faster virtual machine and upgraded
compiler tower. Other additions include compiler macros a la Common Lisp
used for inlining calls to Guile primitives, a reasonably complete FFI,
and Scheme Interaction Mode. The build system has been updated so that
Guile-Emacs can build itself cleanly from a fresh git checkout, with no
assistance from an existing Emacs installation and no undocumented
command line jiggery-pokery. Now the build procedure is "./configure &&
make".

Furthermore, I made a number of modifications to low-level support code
for Guile compatibility. The TL;DR on this is that the language changes
introduced in Guile-Elisp shouldn't matter much for normal programs, but
do require adjustment to low-level code, including debuggers,
macroexpanders and code-walkers. I'll write up a summary of the
differences separately, but the intent is that Guile-Emacs should be no
more disruptive than the addition of lexical binding from an Elisp
programmer's perspective.

For more information on Guile-Emacs, please see the Wiki page at
<http://www.emacswiki.org/emacs/GuileEmacs>, and keep an eye on
<http://www.guile-emacs.org/> for future updates.

Happy hacking,
Robin
-- 
Inteligenta persono lernas la lingvon Esperanton rapide kaj facile.
Esperanto estas moderna, kultura lingvo por la mondo. Simpla, fleksebla,
belsona, Esperanto estas la praktika solvo de la problemo de universala
interkompreno. Lernu la interlingvon Esperanton!