Re: Guile emacs thread (again)

From: Robin Templeton Subject: Re: Guile emacs thread (again) Date: Thu, 18 Sep 2014 08:23:45 -0400 User-agent: Gnus/5.13 (Gnus v5.13) Guile-Emacs/24.4 (gnu/linux)

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 -- 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!

reply via email to

