[[!meta title="Beguiling Emacs: Guile-Emacs relaunched!"]] [[!meta copyright="Copyright © 2024 Robin Templeton"]] [[!inline pages="internal(2024/info/guile-nav)" raw="yes"]] # Beguiling Emacs: Guile-Emacs relaunched! Robin Templeton (they/them) IRC: robin on libera.chat; Fediverse: [@lispwitch@octodon.social](https://octodon.social/@lispwitch); Matrix: [@terpri:matrix.org](https://matrix.to/#/@terpri:matrix.org); website: ; mail: [[!inline pages="internal(2024/info/guile-before)" raw="yes"]] [The Guile-Emacs project](https://guile-emacs.org/) seeks to develop new foundations for Emacs, building on forty years of development to prepare the way for the next forty. Guile-Emacs brings Emacs and Guile together by providing a new Elisp implementation based on Guile's compiler technology, serving as the basis for a more expressive and extensible version of Elisp. We envision Guile and Emacs being co-developed in a sort of mutualism, with Emacs becoming the heart of a "Lisp machine for the 21st century" and with Guile fulfilling the promised role of Lisp from the GNU Manifesto. Guile-Emacs is now being developed by a democratic workers cooperative, focused on development of the project itself and related components of the GNU system. In this talk, I'll cover: - What is Guile-Emacs, in terms of its goals and general architecture? Why is Guile well-suited to the goals of the project? - How did the Guile-Emacs project begin, and what is its status today? - What are the immediate tasks for Guile-Emacs development, and how will they improve Guile-Emacs itself as well as its component projects? - How are our long-term goals for Guile-Emacs connected to the spirit of Emacs and the GNU Project in general? What do we envision for the future of GNU Emacs? - How can you get involved with and support this effort? Along the way, we'll show live demos of Guile-Emacs itself and its extensions to Emacs Lisp. About the speaker: Robin Templeton is a free software advocate who enjoys programming language design and exploring system architecture. Their fascination with Emacs and Lisp lead them to begin work on the then-hypothetical Guile-Emacs project during their university studies. If given the opportunity and interest, they will bless an interested listener with a treasure trove of obscure Lisp history. Guile-Emacs seeks to provide new foundations for Emacs, integrating Emacs and Guile via a new Elisp implementation. We envision a significant role for Emacs within the GNU Project, becoming a central part of a "Lisp machine for the 21st century". # Discussion ## Questions and answers - Q: About fibers: My understanding is that the problem with making Elisp concurrent is that none of the data structures (buffer, cons, vector, window etc) are concurrency-safe.  How do fibers help with this? - A: Fibers do not provide thread-safety for any of the existing data structures.  They are useful for building things that don\'t use Emacs data structures, like a network client that reads a \"stream\".  Fibers can introduce new data structures that are thread-safe, like \"thread-local buffers\". - Q: \ You mentnioned that Emacs is roughly 25% written in C. Do you have a rough idea of how much of Guile is written in C? Could it be an improvement to make libguile a dependency of Emacs? - A: The problem is not the quantity of C, but that there is C involved at every single level/layer of computation in Emacs.  This makes it difficult to use concepts like delimited continuations, that can make it easy to implement Emacs concepts more simply. - A: About guile: it\'s about 1/2 C. - Q: A Common Lisp implementation for Guile sounds really cool! Is there already work on this underway? - A: Yes, Robin is working on it, but focuses more on research on how to do a polyglot lisp environnement where elisp and common-lisp can work together (with lisp 1 vs lisp 2 issues with different name spaces, package and module system interaction, \...). If you are interested, the guile project will work on it. - Q: As someone who\'s kinda new to the concept of Guile, is the primary goal to transpile Emacs Lisp into Guile bytecode rather than primarily focusing on adding support for writing code in Guile\'s Scheme interface in particular?  - A: - Q: Did switching from guile 2 to 3 give any performance benefits? - A: Not benchmarking stuff here yet, because guile emacs has too much overhead involved in conforming to Emacs.  Have not noticed a perceptible change.  Based on the Gabriel benchmark results, it might have benefited a  bit, but for Emacs we don\'t know yet.  Lowering the overhead is the best place to focus on to optimize guile-emacs. - Q: Do you know if the Emacs maintainers are interested in switching to Guile as the engine for Emacs Lisp? - A: Previous maintainers were cautiously optimistic and interested. Issues might be cross-platform compatibility. - Q: Do you think guile-emacs will be able to use or (collaborate with) some of the other awesome projects around Emacs-Lisp, like the gypsum project presented earlier today, or Andrea Corallo\'s efforts to make Emacs-Lisp more suitable for native compilation? Or even something like the renewed PreScheme efforts? - A: Gypsum has a different focus. Guile tries to improve lisp instead of replacing lisp in any way. But some code can be shared, especially if some parts of emacs are rewritten in lisp - A: For libgccjit: it is accelerating the interpreter, which is not great in the first place. So no direct relationship. - A: For prescheme: it  is a useful tool to look at, making it easier to upstream one day. - Q: SBCL, \...You mentioned Robert Strandh\'s SICL along with SBCL---does that work help with the implementation of CL in Guile?  - A: Time consuming part are the DSL from common lisp. So they can be used. No plan on sharing code yet, as they are open-source. - Q: Can you comment more on relation with hoot project and advantages that might bring to guile-emacs? - A: Hoot is only tested on scheme decompilation. But it is a completely different project. One could image compile emacs to wasm and maybe with a different garbage collector. - Q: - A: ## Notes - [https://guile-emacs.org/](https://guile-emacs.org/) - Some more motivation: avoid FFI to increase performance and allow for more optimizations (including type annotations) [[!inline pages="internal(2024/info/guile-after)" raw="yes"]] [[!inline pages="internal(2024/info/guile-nav)" raw="yes"]]