6 ms·

Clarifying some things about Guile-Emacs

147 points by paroneayea 12y ago

JasonFruit 12y ago
Also notice on a different branch of the thread, where rms says, "Guile is the direction we should go, if at all possible." It sounds to me like Guile, at least as Emacs' elisp implementation, is one way Emacs could go, a way it should go, and the way rms says it should go; all that suggests strongly that it is the way it will go.
- naner 12y ago
  https://lists.gnu.org/archive/html/emacs-devel/2014-09/msg00527.html https://lists.gnu.org/archive/html/emacs-devel/2014-09/msg00... Heh, nice email header. Guile is an old GNU project (https://www.gnu.org/software/guile/manual/html_node/History.html https://www.gnu.org/software/guile/manual/html_node/History....), it languished for a long time but recent developments have really pushed it forward.
  - chriswarbo 12y ago
    > Guile is an old GNU project, it languished for a long time but recent developments have really pushed it forward. A bit like Emacs then ;) (it seems much more active around v24 onwards)
    - fafner 12y ago
      Once rms stepped down as a maintainer development around GNU Emacs seemed to have significantly improved. It is amazing to see the progress. Although the 24.4 release keeps waiting.
- mapcar 12y ago
  rms also said emacs should incorporate word processing features too. ...what about that part?
- bjourne 12y ago
  Yup, but RMS doesn't maintain Emacs anymore, Stefan Monnier does. And he is not fond of Guile. So it's loaded for mailing list drama. Note though that RMS is still very much active in Emacs development even if he stepped down as the head a few years ago.
mapcar 12y ago
I think the most important thing would be for the community to understand what ports and what doesn't port from the elisp version that everyone uses- until then I don't think many will be able to make an informed decision regarding the risks of migrating.
- rcthompson 12y ago
  It looks like it's supposed to be backwards-compatible with pretty much all existing elisp code.
  - jahnu 12y ago
    Out of interest, is common lisp similarly compatible?
    - espadrine 12y ago
      Your question is invalid, so answering it is impossible, but it is a very normal mistake to make, so you have no reason to feel bad about it. Common Lisp is a language, while what they are integrating to Emacs isn't a language, it is a VM used by an implementation of a language. The VM itself is generic enough to be compatible with Elisp (although I believe there was some struggle to deal with the differing way nil and #t work between Elisp and the Guile VM). It is a bit like how both Java and Ruby can run on the JVM, Java being born with it and Ruby being ported to it through JRuby. A particular implementation of Common Lisp can have a VM that is similarly compatible with Emacs, although all GNU Common Lisp implementations are not as actively maintained as Guile is. On the language side, Common Lisp is definitely incompatible with Elisp, as they have differing semantics. Historically, Common Lisp has had lexical binding, while Elisp has dynamic binding. (From Emacs 24 on, one can turn on lexical binding on a file by file basis.) Elisp also doesn't have closures. Finally, the numeric tower is different between the two.
      - lispm 12y ago
        Common Lisp implementation also tend to not use VMs too much nowadays. GNU CLISP has a VM. ABCL runs on top of the JVM. CMUCL can run on a VM. But that's mostly it. The rest uses native code, either directly or via C.
josteink 12y ago
Awesome! I like how he clarifies what this is, isn't and what state it is in. I was definitely wondering where this project was and where it was heading. I also appreciate how he claims it build cleanly too. Almost feel like building it and trying it myself :-)
jwr 12y ago
This is a good clarification. I was worried about Scheme becoming the "official" Emacs extension language, which I think is a bad idea. Getting a better/faster Elisp engine is a good goal. I can't help but think that Emacs is a local maximum: it works well enough that people don't take on the task of implementing huge changes. People who demand a lot from Emacs learn how to do things in Elisp and just get on. As for the future, I would love to see an Emacs implemented in Clojure (no, not ClojureScript, Clojure on the JVM). I think approaching this task with any Lisp-like language other than Clojure is misguided, because it doesn't take concurrency into account. Clojure is the only Lisp-family language which gets concurrency right. Also, I'd love to have easy access to Java libraries. But, that's just me dreaming.
- josteink 12y ago
  Being based on Clojure for good and bad also means being dependant on the JVM. Not taking RMS's stance on Free software with a capitol F into account (and make no mistake that Emacs is RMS's baby, it wont happen), the JVM is a troublesome dependency in itself. OpenJDK has terrible performance. Oracle JVM has terrible licensing and platform support. For the "emerging" platforms such as ARM that means that anything based on JVM is inaccessible, unless you are willing to accept a 30 second+ startup-time for any JVM based application. If you have any doubts about this, try getting Clojure and the appropriate tooling working on a Raspberry Pi. You will be tearing your hair out before having written a single line of code. While the rest of the Linux userland (based on C) just flows by at a nice regular speed. The JVM situation (either open, supported and slow, or not supported at all) makes Clojure a no-go on this entire platform. While I'm not saying we should limit Emacs to what runs well on a RPi, I think it's worth considering ARM as a critical platform to support in the future, and the JVM has no room there. At all.
  - rjsw 12y ago
    OpenJDK performance seems fine to me, on platforms that have HotSpot support. I'm not arguing that Emacs should target the JVM but don't see how building it on yet another bytecode VM is going to fix any performance problems.

147 points by paroneayea 12y ago

Also notice on a different branch of the thread, where rms says, "Guile is the direction we should go, if at all possible." It sounds to me like Guile, at least as Emacs' elisp implementation, is one way Emacs could go, a way it should go, and the way rms says it should go; all that suggests strongly that it is the way it will go.

naner 12y ago
https://lists.gnu.org/archive/html/emacs-devel/2014-09/msg00527.html https://lists.gnu.org/archive/html/emacs-devel/2014-09/msg00... Heh, nice email header. Guile is an old GNU project (https://www.gnu.org/software/guile/manual/html_node/History.html https://www.gnu.org/software/guile/manual/html_node/History....), it languished for a long time but recent developments have really pushed it forward.
- chriswarbo 12y ago
  > Guile is an old GNU project, it languished for a long time but recent developments have really pushed it forward. A bit like Emacs then ;) (it seems much more active around v24 onwards)
  - fafner 12y ago
    Once rms stepped down as a maintainer development around GNU Emacs seemed to have significantly improved. It is amazing to see the progress. Although the 24.4 release keeps waiting.
mapcar 12y ago
rms also said emacs should incorporate word processing features too. ...what about that part?
bjourne 12y ago
Yup, but RMS doesn't maintain Emacs anymore, Stefan Monnier does. And he is not fond of Guile. So it's loaded for mailing list drama. Note though that RMS is still very much active in Emacs development even if he stepped down as the head a few years ago.

mapcar 12y ago

I think the most important thing would be for the community to understand what ports and what doesn't port from the elisp version that everyone uses- until then I don't think many will be able to make an informed decision regarding the risks of migrating.

rcthompson 12y ago
It looks like it's supposed to be backwards-compatible with pretty much all existing elisp code.
- jahnu 12y ago
  Out of interest, is common lisp similarly compatible?
  - espadrine 12y ago
    Your question is invalid, so answering it is impossible, but it is a very normal mistake to make, so you have no reason to feel bad about it. Common Lisp is a language, while what they are integrating to Emacs isn't a language, it is a VM used by an implementation of a language. The VM itself is generic enough to be compatible with Elisp (although I believe there was some struggle to deal with the differing way nil and #t work between Elisp and the Guile VM). It is a bit like how both Java and Ruby can run on the JVM, Java being born with it and Ruby being ported to it through JRuby. A particular implementation of Common Lisp can have a VM that is similarly compatible with Emacs, although all GNU Common Lisp implementations are not as actively maintained as Guile is. On the language side, Common Lisp is definitely incompatible with Elisp, as they have differing semantics. Historically, Common Lisp has had lexical binding, while Elisp has dynamic binding. (From Emacs 24 on, one can turn on lexical binding on a file by file basis.) Elisp also doesn't have closures. Finally, the numeric tower is different between the two.
    - lispm 12y ago
      Common Lisp implementation also tend to not use VMs too much nowadays. GNU CLISP has a VM. ABCL runs on top of the JVM. CMUCL can run on a VM. But that's mostly it. The rest uses native code, either directly or via C.

josteink 12y ago

Awesome! I like how he clarifies what this is, isn't and what state it is in. I was definitely wondering where this project was and where it was heading. I also appreciate how he claims it build cleanly too. Almost feel like building it and trying it myself :-)

jwr 12y ago

This is a good clarification. I was worried about Scheme becoming the "official" Emacs extension language, which I think is a bad idea. Getting a better/faster Elisp engine is a good goal. I can't help but think that Emacs is a local maximum: it works well enough that people don't take on the task of implementing huge changes. People who demand a lot from Emacs learn how to do things in Elisp and just get on. As for the future, I would love to see an Emacs implemented in Clojure (no, not ClojureScript, Clojure on the JVM). I think approaching this task with any Lisp-like language other than Clojure is misguided, because it doesn't take concurrency into account. Clojure is the only Lisp-family language which gets concurrency right. Also, I'd love to have easy access to Java libraries. But, that's just me dreaming.

josteink 12y ago
Being based on Clojure for good and bad also means being dependant on the JVM. Not taking RMS's stance on Free software with a capitol F into account (and make no mistake that Emacs is RMS's baby, it wont happen), the JVM is a troublesome dependency in itself. OpenJDK has terrible performance. Oracle JVM has terrible licensing and platform support. For the "emerging" platforms such as ARM that means that anything based on JVM is inaccessible, unless you are willing to accept a 30 second+ startup-time for any JVM based application. If you have any doubts about this, try getting Clojure and the appropriate tooling working on a Raspberry Pi. You will be tearing your hair out before having written a single line of code. While the rest of the Linux userland (based on C) just flows by at a nice regular speed. The JVM situation (either open, supported and slow, or not supported at all) makes Clojure a no-go on this entire platform. While I'm not saying we should limit Emacs to what runs well on a RPi, I think it's worth considering ARM as a critical platform to support in the future, and the JVM has no room there. At all.
- rjsw 12y ago
  OpenJDK performance seems fine to me, on platforms that have HotSpot support. I'm not arguing that Emacs should target the JVM but don't see how building it on yet another bytecode VM is going to fix any performance problems.