Re: Guile emacs thread (again)

[Christopher Allan Webber]

Robin Templeton writes:

> Christopher Allan Webber <address@hidden> 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

Hey Robin, thanks for this really great email.  I was excited for
guilemacs before, but I'm even more excited now.  :)