diff options
Diffstat (limited to '2024/talks')
| -rw-r--r-- | 2024/talks/guile.md | 69 | 
1 files changed, 69 insertions, 0 deletions
diff --git a/2024/talks/guile.md b/2024/talks/guile.md index 98e49df8..3c82627b 100644 --- a/2024/talks/guile.md +++ b/2024/talks/guile.md @@ -58,6 +58,75 @@ 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: +-   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/){rel="noreferrer noopener"} +-   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"]]  | 
