Clarifying some things about Guile-Emacs

https://lists.gnu.org/archive/html/emacs-devel/2014-09/msg00559.html

by paroneayea • 12 years ago

147 30 12 years ago

lists.gnu.org

JasonFruit• 12 years 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• 12 years ago

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....), it languished for a long time but recent developments have really pushed it forward.

chriswarbo• 12 years 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)

mapcar3• 12 years ago

rms also said emacs should incorporate word processing features too. ...what about that part?

bjourne• 12 years 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.

mapcar3• 12 years 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.

rcthompson2• 12 years ago

It looks like it's supposed to be backwards-compatible with pretty much all existing elisp code.

jahnu• 12 years ago

Out of interest, is common lisp similarly compatible?

mapcar3• 12 years ago

Right, it's the "pretty much" part that's a little disturbing. Would be nice to know why this caveat is always thrown around.

josteink2• 12 years 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• 12 years 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.

josteink2• 12 years 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• 12 years 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.

quadcore4• 12 years ago

> As for the future, I would love to see an Emacs implemented in Clojure
Being based on Clojure for good and bad also means being dependant on the JVM. {snip} The JVM situation (either open, supported and slow, or not supported at all) makes Clojure a no-go on this entire platform.

Maybe the solution is that we need a Clojure implemented on Guile.

Edit: That would make a number of groups of people happy:

* the free-software advocates who like Clojure don't like its current license (EPL)

* the folks who like Clojure but don't want to use the JVM or anything else Java-related

* the people who want to use Clojure on JVM but cannot tolerate its slow start-up time and/or high memory usage

* the group who would like to re-implement Emacs, but not in Elisp, Scheme, or CL

* (Edit 2) the Guile dev team, who would get an influx of new users

* (Edit 3) GNU folks, who would see more people exposed to GNU and Guile

Aside, not sure what the multi-threading story of a Guile-Clojure would look like.

AceJohnny2• 12 years ago

I was worried about Scheme becoming the "official" Emacs extension language, which I think is a bad idea.

Why is that? I'm a complete novice to Emacs programming (depsite using it for about a decade), and I'm always bouncing off Elisp's warts (for a quick overview Steve Yegge's post [1] was the most useful to me). For example, the need for progn in a multi-statement "then" clause of if-then-else. I just wish we could have a cleaner alternative.

Of course, there's a huge landscape of powerful, working, and well organised Emacs extensions written in Elisp, so for that reason alone I understand the need to keep it around.

[1] http://steve-yegge.blogspot.com/2008/01/emergency-elisp.html

spopejoy• 12 years ago

I like Clojure and all, but this is just ... silly.

First, 100% elisp compatibility is the no-exceptions requirement. Clojure doesn't have freakin' car and cddadr, not to mention the significant syntax differences. LISP weenies don't even think Clojure is a proper LISP, whereas elisp comes close to a functional subset of CL.

Next, the JVM. There's lots to like about the JVM, but it's not particularly well-suited for embedding in a text editor, which is why JEdit hasn't taken over the world. It's also not compact. The last thing Emacs needs is batteries-included Java being loaded up.

Multithreading: guile can do it, and emacs doesn't need industrial strength or crazy map-reduce. We just need emacs not to hang whilst TRAMP calls 'ls' on a remote server. Freaking timesharing would work, modern machines are more than fast enough with one thread.

Putting clojure in emacs would basically be starting over, on the wrong foot. I'd rather rebuild on GHC.

lispm3• 12 years ago

Hmm, I use an Emacs written in a Common Lisp all the time... using concurrent threads.

wglb• 12 years ago

Which one is that?

Clarifying some things about Guile-Emacs

Related Stories