If I was them, I'd gradually introduce the minimum set of breaking changes to ELisp that converge it on Common Lisp. Even if those changes were unhelpful or removed features. Then eventually, when it maps 1:1 onto a subset of CL, just swap the implementation for a supported CL.
Some years ago the a clisp maintainer actually made a minimal demo of Emacs hosted on clisp with just a compatibility layer for Elisp via macros/functions, which seemed to work pretty well. But it didn't progress any further because Stallman vetoed basing Emacs on Common Lisp (he considers CL to be too big a language, and to some extent just doesn't like it). In retrospect I'm not sure this was a good call: Guile as a general VM with custom infrastructure to support both Scheme and Elisp is not really a more clean, minimalistic infrastructure anyway. The semantics of Elisp/Scheme are too different to be able to just stick in a Scheme implementation with a smallish compatibility layer, like you could with Elisp hosted on CL.
>Guile as a general VM with custom infrastructure to support both Scheme and Elisp is not really a more clean, minimalistic infrastructure anyway
Guile is already a general VM meant to support many different languages, not only Scheme. I think it's a very clean solution to use Guile's efficient VM, and I don't think minimalistic is a useful criterion.
Are you sure that Richard Stallman does not like Common Lisp?
Several years ago he asked me about the possibility of my releasing my out of print Common Lisp book (published by Springer-Verlag) under the GNU documentation license. I would have liked to do that but I couldn't find my manuscript word processing files.
If he made the opposite call, and adopted CLisp, you'd be complaining about him anyway, in a thread about some unexpected compatibility problem or whatever.
Uh, no. Common Lisp is sensible. It's multi-implementation and several of the implementations are JVM levels of fast, while others are highly portable. There's a community, standards, and libraries. It's not where the froth of lisp experimentation is happening, but it's effective and a known quantity.
RMS is fine with an FFI as long as you cannot use it to inject non-free code. This is usually done by requiring an exported symbol saying that the code is GPL compatible. GCC does it this way:
But you cannot call that a FFI then. A FFI is the abbrevation for "Foreign Function Interface", not "Friendly Function Interface". FFI's are not sugar coated.
