taylanub

You're talking out of ignorance, keep it down.

Guile-Emacs runs Elisp, not Scheme, and Elisp will remain the main Emacs language for a long time. Using Scheme will become a possibility and you can bet on some people starting it immediately, but nobody is forced.

Guilifying Emacs is not "pushed by the Guile guys," it's always been RMS's desire.

The "Emacs guys" is a rather large group of people, which is essentially a superset of "Guile guys." Some of them would love Scheme, others wish it was CL instead, others want to take Elisp on its own path to evolution. Guile offers an evolved Elisp, and Scheme as an addition. And of course One Day someone might sit down and implement CL for Guile too, you never know.

GCC, GDB, GNU Make, and some other tools can be extended in Guile. The Nix-derived package manager Guix which forms the core of the upcoming official GNU distribution is also written in Guile. It's becoming quite "relevant" on its own terms. But sure, Emacs would be a huge boost. They're both GNU software so it's a logical come-together if you ask me.

So is BT Templeton, the person who has been hacking away at Guile-Emacs GSoC after GSoC. :-)

(They seem very skilled, don't be fooled by the fact that it's GSoC; no idea what the skill level of people who take part in that usually tends to be.)

Note that using the `not' and `null' functions instead of comparing equality to `nil' is good coding style anyway.

Guile-Emacs is not a rework, it's a rebase. It already runs all Elisp, sans bugs and (currently severe) performance regressions. It will be a nearly-drop-in replacement, a new version of GNU Emacs, even less different from it than XEmacs. In general, it will only add to Emacs, and change the underlying implementation of Elisp.

Even in the current pre-alpha/alpha stage of Guile-Emacs, I can launch a thread from Scheme, do work, return to the main thread, then call an Elisp function on my result. (Scheme and Elisp data types are unified.) No bugs or unpleasant details there.

Calling Elisp functions and accessing Emacs data types (buffers, windows) from multiple threads is another issue; if you don't want to bother with it then don't; you still get all the other benefits of being on Guile. (Calling to any Guile module agnostically as if it were an Elisp library (including, say, Guile's OpenGL module), having an FFI, getting JIT or AOT native compilation in the future, etc.)