diff options
Diffstat (limited to '')
| -rw-r--r-- | 2024/talks/guile.md | 177 |
1 files changed, 155 insertions, 22 deletions
diff --git a/2024/talks/guile.md b/2024/talks/guile.md index e00b075a..1bd72def 100644 --- a/2024/talks/guile.md +++ b/2024/talks/guile.md @@ -7,38 +7,41 @@ # Beguiling Emacs: Guile-Emacs relaunched! -Robin Templeton (they/them) - IRC: robin, - robin on libera.chat - Matrix: @terpri:matrix.org - Mastodon: @lispwitch@octodon.social - Website: <http://terpri.org/>, <mailto:robin@terpri.org> +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: <http://terpri.org/>; mail: <mailto:robin@terpri.org> [[!inline pages="internal(2024/info/guile-before)" raw="yes"]] -The Guile-Emacs project seeks to develop new foundations for Emacs to -serve as the basis for the next forty years of development. It -integrates Emacs and Guile by providing a new Elisp implementation based -on Guile's Lisp-oriented compiler tower and runtime environment. -Guile-Emacs is being developed by a new, publicly-funded democratic -workers cooperative, founded to support development of Guile-Emacs -itself and Free Software in general. We envision Guile and Emacs being -co-developed in a sort of mutualism, along with other components of the -GNU system, and for Emacs to become a central part of what we describe -as "a Lisp machine for the 21st century", and to help fulfill the -promised role of Lisp outlined in the original GNU Manifesto. +[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 exactly is Guile-Emacs, in terms of its goals and general - architecture? What is it, and what is it not? Why is Guile in - particular well-suited to the goals of the project? -- What is its history and current status? What can one already do with - Guile-Emacs? -- What are the immediate tasks for Guile-Emacs development, and how will - they improve Guile-Emacs itself and Emacs in general? +- 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 I get involved with and support this effort? +- How can you get involved with and support this effort? -Along the way, we'll show brief code samples and live demos of Guile's -Elisp implementation and Guile-Emacs itself. +Along the way, we'll show live demos of Guile-Emacs itself and its +extensions to Emacs Lisp. About the speaker: @@ -55,6 +58,136 @@ 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: <ramin\> 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: (not yet answered) +- 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: Thoughts on the gui situation for guile-emacs? A dom gui backend would be amazing + - A: (not yet answered) +- Q: is the "initial rebase work repo" the latest/preferred archive? i sent two patches to guile-emacs-devel to get emacs to link, but cannot get it to dump just yet: No applicable method: function-documentation + +## Notes and feedback + +- [https://guile-emacs.org/](https://guile-emacs.org/) +- Some more motivation: avoid FFI to increase performance and allow + for more optimizations (including type annotations) + +- Love to hear reduction of reliance on C highlighted as a project goal, it's something I've brought up as a "third perspective" vs performance and language ergonomics in this weeks discussions +- my other go-to discussion contrib is "is anyone watching what Larry Valkama is doing?" +- is guile the core of gnu guix too ? + - yep! + - well, there's a bit of C++, bits of shell and make, yk -- more complex under the hood >u< + - but it's the core in spirit + - this is really interesting because this means gnu guix can use guile emacs and have better performance / features ? like define the system and emacs too with guile right? (I never used gnu guix but this talk makes me one to install it right now :P) + - I'm not sure there are really any implications for GUIX here, besides more eyeballs on Guile + - robin: there may be a guix connection in that object-capability-based secure IPC may enable guile-emacs to have fairly deep integration with other guile programs like guix and shepherd +- Ahhhh~ I love to see tail-call optimization 😊 +- Is the goal to keep rebasing forever? Seems like a lot of work without little benefit + - Ah here's the slide addressing that... +- Woohooo wasm via hoot! +- i've def heard from a lot of guix users who are primarily interested in using one language everywhere, just on the edge of the performance and lang-interop disscusions +- why would you want to use emacs in a web browser? + - maybe because you can use emacs shortcuts on it ? + - wasm != web browser + - there's wasi + - exactly, Larry mentions emacs on wasm in his readme too, but i try not to use the web as my example when talking about porting away from C bc i find alternatives more compelling + - though tbf, *i* would love to be able to hit a shortcut from org-roam-ui and have it open emacs in-browser like vscode on github + - Not convinced that browsers equipped with WASM and WASM-GC are actually more portable than Emacs today + - it sucks that browser shortcuts conflict with Emacs keybindings + - That's due to the browser, not the underlying engine tho +- Ahhh you thought the CL bit would piss us off! Joke's on you, love CL ;) +- not as much as you might expect! boot-9.scm is a great place to look to see the world being built up in parens +- robin: thanks for watching my guile-emacs talk everyone! just one update, the -announce list may not be working properly yet, so please subscribe to guile-emacs-discuss if you want to stay informed about future guile-emacs work + - (the hcoop.net admins should be back to fix that in a few hours) +- robin: and thank you corwin for convincing me to do an emacsconf talk in the first place :) + - Thanks so much, robin and corwin! + +Feedback: + +- 👏👏👏👏 +- Great! Thank you +- Utterly fantastic. This is so, so exciting! +[13:41:59] * gs-101 claps +- 👏👏👏 +- 👏👏👏 +- 👏👏👏 +- 👏👏👏 +- 👏👏👏👏 +- Thank you Robin! +- 👏👏👏👏 +- *applause* the dead are rising! +- This bring back memories of Smalltalk implementations being written in Smalltalk after initially being written in C. +- I utterly love Common Lisp 😊 +- cl-lib is already a fifth of quality elisp (/s?) +- heh I feel this pain trying to get Wayland, CLIM, and OpenGL working +- in CL +- 👏 👏 +- O_O +- I really liked robins talk +- great work, great talk -- thank for your work O) +- short and sweet, thank you +- +1 + +- <3 +- lounge-204, there may be a guix connection in that object-capability-based secure IPC may enable guile-emacs to have fairly deep integration with other guile programs like guix and shepherd +- robin: speaking of security, guile-emacs will have a very straightforward answer to problems like https://eshelyaron.com/posts/2024-11-27-emacs-aritrary-code-execution-and-how-to-avoid-it.html -- the application of the slogan "if you don't have it, you can't use it". ordinary elisp coding style doesn't necessarily allow for automatic detection of that kind of threat, but in that specific case we would use our CL dialect's reflection mechanisms to provide an environment in which the macroexpander, at least when used for code completion and similar, simply would not have the ability to produce side effects in the global environment +- YouTube comment: we're so back bless you robin [[!inline pages="internal(2024/info/guile-after)" raw="yes"]] |