Look, neither Common Lisp nor any Scheme implementation are exactly topping the charts in popularity these days. This should be about the technical merits of the choice, because I'm pretty sure Emacs Lisp both has more code and more programmers (both represented in the forms of small scripts we've shoved into scratch and evaluated) than both.
The decision to go either Common Lisp or Scheme was made based on RMS very personal reasons and conflicts with close-source Lisp machine companies during the first half of the 80s.
GNU has had two common Lisp implementations under their umbrella at least since mid 90s (CLISP (of Viaweb fame) and GCL (of Maxima fame)), but due to RMS' hate of Symbolics and Common Lisp, all of the effort was invested into making Guile run properly (which took them 25 years and still nobody is using it) and the two Lisps were basically orphaned.
The latest effort of guile-ifying Emacs is more pushed by the Guile guys, in order to attach themselves to an already existing killer app (emacs) and to basically force more and more people to use Scheme, because nobody is doing it voluntarily.
The Emacs guys, as you see from the post, are not _really_ excited about the idea of switching to another _language_. They want FFI, multithreading, etc, but they do not necessarily want Scheme. Actually they dont want Scheme at all, adopting Scheme would be just a price to get FFI, etc.
Of course the proper way would be to go Common Lisp. Elisp is and has always been a subset of Common Lisp, and they've had a Common Lisp compatibility layer for decades, and a lot of packages use it. The problem is simply highly political. You'd have to confront RMS, and you'd have to finally get rid of Guile's "official GNU extension language" status.
My (potentially misunderstood) interpretation of why ELisp exists is due to the fact that Scheme was unsuitable because it's lexically scoped (which was potentially less efficient). The dynamic scope of ELisp is advantageous for things like temporary mode mapping changes, buffer local variables, etc (See: https://www.gnu.org/software/emacs/emacs-paper.html#SEC17).
Scheme of course provides `fluid-let` and Common Lisp also allows for dynamic binding
> all of the effort was invested into making Guile run properly (which took them 25 years and still nobody is using it)
I think the first release of Guile was in 1995... Did I misinterpret your point?
> The Emacs guys, as you see from the post, are not _really_ excited about the idea of switching to another _language_. They want FFI, multithreading, etc, but they do not necessarily want Scheme. Actually they dont want Scheme at all, adopting Scheme would be just a price to get FFI, etc.
A price some of us don't feel like paying. It might be irrational, but when thinking about switching Emacs to Guile, I feel it's like proposing to sell its very soul. A Guile-powered Emacs would feel... weird (the it-walks-and-talks-but-when-you-look-into-the-eyes-there's-noone-home p-zombie kind of weird) (and don't get me started on ideas like "let's script Emacs in Javascript", like Emacs was a scriptable editor like the others...).
Strangely, I get less of this feeling with Common Lisp, maybe since Elisp is closer to CL than it is to Scheme.
hmm... from reading this I feel like I'm in the minority but I think I'd prefer scheme to CL (I have to emphatically agree that thinking of a javascript-emacs makes me shudder).
Something about the macros not being hygienic in CL bothers me. I know it's alright as long as you don't redefine anything you shouldn't be redefining but it seems less elegant, and since we're using lisps anyway I feel we should search for the most elegant implementation.
Full disclosure, I don't know too much about Common Lisp so if anyone wants to point out some ways in which it is more elegant than scheme it'd be much appreciated.
> I feel like I'm in the minority but I think I'd prefer scheme to CL
Yeah, I don't get it either. Either is fine with me, though I prefer Scheme to elisp or common lisp. Scheme feels cleaner to me but I don't think I really care except that you need a good implementation of either.
I've been programming with ELisp, CL and Scheme for a long time. Somehow Guile feels like an odd choice. Why not Chicken scheme, or Racket, or Bigloo; which are the top scheme environments you can choose from?
AFAIK, Guile is not used much beyond a few random projects. Maybe I just don't know Guile, really. Maybe it has a decent implementation afterall.
However, I would have gone CL.
There are several "emacs-like" editors implemented in CL:
Guile was designed as an extension language, which CL was not. So, that's one reason. Guile also has a something like 90% working implementation of an elisp compiler to guile bytecode, a JavaScript implementation and (I think, though may be wrong) a working Lua compiler. None of the other mentioned scheme implementations were designed for embedding, even if they are fine implementations themselves (which they are).
If we consider "designed for embedding" as a driving point we can always take ECL (embeddable/extensible common lisp) as a base and get both very nice ffi and threading while still being CL.
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.
People seem to think that moving to Guile means moving to Scheme. It does not. It means that Elisp will run on Guile's VM, which will bring many practical advantages. Emacs will not be switching to Scheme. Elisp will still be used and the Elisp language can continue to be developed.
Can you explain more what FFI support would give? I understand that Emacs is a C+Lisp system. Is it about calling other languages from Elisp easier? Or possible at all?
