Hacker News Reader

Comment by avar | Hacker News Reader

For those excited about the "Guile's Elisp implementation" in this release. The last major Guile release was 6 years ago, and much of this GuileEmacs work is still highly WIP and from my searching on emacs-devel seems to have stalled in 2015 for lack of volunteers.

Just because Guile implements Elisp the language doesn't mean there isn't a ton of work to be done on Emacs itself to swap out its native VM for Guile, and it seems nobody's keen on finishing up that work.

View on HN

Given that Guile was basically launched by an RMS FUD attack on Tcl more than 20 years ago, 6 years seems like a rounding error.

http://vanderburg.org/old_pages/Tcl/war/

It's been 6 years since Guile 2.0, when Guile went from being an interpreter only to having a VM and AOT compiler.

You mean a jit compiler. There is still not AOT compiler for GNU Guile AFAIK. Except janneke work.

Guile uses an ahead of time (AOT) compiler. Someone wrote an experimental tracing JIT recently [0] but that's not part of Guile itself.

[0] https://github.com/8c6794b6/guile-tjit

I believe in theory it also uses Lightning[1], but I can no longer get Lightning to build since GCC 6 or so, so I can't verify that.

[1]: https://www.gnu.org/software/lightning/

There is an AOT compiler from source to bytecode, and then there is a bytecode interpreter. Wingo is considering the possibility of having a bytecode-to-native JIT or a source-to-native compiler.

Tcl was accused of being a scripting language that is more suitable for simple scripts, so I went and took a look at the Wikipedia article to see if it too presented a similar view. To quote: "It is commonly used embedded into C applications,[9] for rapid prototyping, scripted applications, GUIs, and testing.[10]"

Is wikipedia also doing a fud attack on Tcl (as it naturally could be the case), or is RMS post simply a less diplomatic and less friendly way to say that Tcl don't have the same purpose and use case as languages like c and c++? Any turning complete language can of course be used for anything, but looking at how something is used often give a good hint on where its strengths are.

At the time, Tcl was being used for fairly large apps (and it still is, e.g. in WaveSurfer). As for large scale suitability, I would guess that both Tcl and guile nowadays are eclipsed by Lua for embedded scripting, which to me would suggest that "simple" won out over "powerful".

What is not mentioned in that thread (at least not in RMS' original message) is that what triggered his edict was that somebody extended gdb with Tcl as the extension language. This was an absolutely reasonable use case for Tcl - the lightweight syntax makes it perfect as an interactive, embedded scripting language.

This discussion led to the creation of Guile, the withering of Tcl support in gdb, and eventually the introduction of a gdb that used Guile as its extension language — in 2014, 20 years after RMS decided that the Tcl extension (which I believe pretty much worked already) was unacceptable.

Of course, as astute readers will already have guessed, Tcl was BSD licensed...

Your narrative omits that gdb added Python scripting support in 2009.

Of course, as astute readers will already have guessed, Python is permissively licensed.

Both true, but I did not want to further digress. I would argue that the fact that it took 15 years for scripting support to show up again is evidence that the original policy was counter-productive.

that's fantastic context; thanks for pointing this out.

What's left to be done?

I'm not involved in Emacs/Guile/GuileEmacs development. I just searched emacs-devel / EmacsWiki before writing that comment.

Having said that it seems to be in a POC state, but is very slow and needs optimization. These two wiki pages provide a decent overview: https://www.emacswiki.org/emacs/GuileEmacs & https://www.emacswiki.org/emacs/GuileEmacsTodo

This "Preview: portable dumper," thread from November 2016 and spin-offs appear to be the most up-to-date emacs-devel discussion on the subject: https://lists.gnu.org/archive/html/emacs-devel/2016-11/threa...

The older October 2015 "In support of guile-emacs" thread seems to have been written after development mostly tapered out, discusses some work to be done, and is a call for more development (which seems to have gone unanswered): https://lists.gnu.org/archive/html/emacs-devel/2015-10/threa...

All the work on the Emacs integration appears to have been done by Robin Templeton in early 2015 with no commit since May 2015: http://git.hcoop.net/?p=bpt/emacs.git;a=shortlog

> Thanks to the work of Robin Templeton, Guile's Elisp implementation is now fully Emacs-compatible, implementing all of Elisp's features and quirks in the same way as the editor we know and love.

Robin Templeton also seems to be the one which finished off the elisp compatibility on Guile here so it's probably because he saw that as important to get first.

One big item is that that Emacs' internal string/buffer representation supports things like loading weirdly (or even erroneously) encoded data, and saving this unchanged; this is sometimes quite useful.

Guile's strings (gnulib's) do not support that, and adding the support is quite a bit of works for all the corner-cases that emacs supports.

Now, emacs and guile do not necessarily have to use the same underlying string/buffer implementation, but it would definitely be a big plus, and I wouldn't be surprised the emacs maintainers would require it.

Reply on news.ycombinator.com