I really hope to see Guile Emacs become the canonical GNU Emacs someday. Guile will give Emacs a foundation to add a bunch of features to Elisp that it does not have like delimited continuations. Exciting stuff.
I think the question is more of whether it will make the core semantics of emacs and elisp threaded. Which is a different question compared to whether or not the vm has threads. Right?
I really, really hope that Common Lisp ends up being the next generation engine for emacs. Scheme is a neat language, but it's not the bulletproof industrial behemoth CL is.
RMS seems to just not like CL, so I doubt that will happen. The big advantage of hosting Elisp on CL imo is that Elisp's semantics are a much better match for CL. For example it's trivial to do dynamic scope in CL, but not easily supported in Scheme (the linked TODO implies they've managed to get dynamic scope on top of Guile working, but with poor performance).
This isn't about Emacs changing the implementation language, but changing the VM that Elisp runs on. Don't worry, there won't be any Scheme in your Elisp.
Supporting Emacs extensions written in Scheme is part of the goal I
had in mind when I proposed this. That's the tangible benefit that we
would get from Scheme support. If all Scheme does is serve as a platform
for Emacs Lisp, it is no real advance.
The switch doesn't have to happpen all at once; and, considering how much Elisp would have to be rewritten, it couldn't happen all at once.
Rather, I hope the switch is made gradually, and most of all that Elisp fans don't dig their heels in against it, but rather work to make the transition smoother.
Considering that the push for Guile is not coming from the Emacs community, but from the Guile community in order to promote Guile, I guess that Emacs will be forked as soon as they deprecate Elisp and start forcing people to use Scheme. Switching to Scheme will be GNU Emacs's suicide.
If Emacs and all of its extension code was completely rewritten in Scheme, what would be the point of sticking with Elisp? And how would using a Scheme-only Emacs be "GNU Emacs's suicide"?
What concrete value does Elisp add over Scheme?
CL vs Scheme, I could see an (unconvincing to me) argument for, but Elisp? Elisp?
Don't get me wrong. I'd much rather use Elisp than most any other non-lispy language. I just don't see anything in it to recommend it over a modern Scheme like Guile.
But I'm open to being shown the errors of my ways. What's so great about Elisp? Please enlighten me.
I was rather disappointed this wasn't a port of TodoMVC to Emacs.
Any particular reason this is front-page news? I'm not currently an Emacs user, but I've been considering it. Maybe I'm missing something notable buried in this list.
This article has a concrete set of TODOs for getting that to work, which I suspect appeals to people interested in that general project, but frustrated that it seems to be moving glacially.
This is about the Emacs internals, though. Not (for the moment) necessarily of interest to someone just using Emacs, or contemplating doing so.
The memory and performance regressions are frightening. I don't know enough about the specifics to know that this is a good or a bad idea, but it definitely looks like they have their work cut out for them.
This does remind me of the post from the other day about a time traveler. With an expectation that things will get faster, the opposite seems to be the norm. :(
You can read this as "mainline Guile Emacs is never gonna happen".
Guile is very low quality software (that goes double, hell, triple, for "non free" platforms like OSX and Windows) and Emacs has a reputation for being rock solid on all platforms it runs on.
The Guile fanboys may wish for Guile to replace the current core in mainline but realistically speaking (Guile has what, 1/2 developers?) that's never going to happen.
If I had to guess, I'd say most Emacs users and developers couldn't care less about Scheme/Guile (if not actively hostile).
I'm leaning mostly towards the "couldn't care less" department. Though, I do think it is a shame if there are items we are missing out on because of it.
I am curious on just how many/what features would be on the table with an alternative vm. And then, how hard it would be to just add those features piecemeal instead of moving whole hog?
This lwn.net article from October 8, 2014 [ http://lwn.net/Articles/615220/ ] contains some info and discussion from various developers concerning this topic.
