First of all we need to decide what it really is that is wanted here.
Is it just the underlying lisp engine or what exactly?
Is it basically replacing the C parts with Common lisp code?
That does not seem to gain much.
Is it to discard Emacs lisp entirely (maybe in a longer process) and
replace it with Common lisp
This would discard decades of code and mountains of configurations for
what gain exactly?
Or is the goal to find a mapping of Emacs lisp to Common lisp.
So we can build up the core concepts in common lisp and then map
whatever Emacs code down into Common lisp?
Then people will ask next if in the future can code for Emacs directly
in Common lisp and not just in "legacy" Emacs lisp.
Keeping this distinction in mind is important, especially when talking
to people outside the development group.
A lot of people had very different ideas and interpretations of what
the Emacs-guile project intented to do and did.
Be aware that Emacs lisp is not Common lisp and such a mapping does
have some pitfalls, especially around dynamic scoping and buffer local
variables.
I remember some blogposts about this (from 2012)
http://tromey.com/blog/?p=709 http://tromey.com/blog/?p=751
http://tromey.com/blog/?p=778
Personally I could fear that this mapping will insert certain
restrictions of what can
and can't be done in Common lisp code against Emacs, especially if we open up to
everyday Emacs code in Common lisp. Basically it would be problematic if Common
lisp could violate certain assumptions the Emacs code makes, like
running "single threaded".
Maybe this could be contained by hiding it somehow, but isn't all we
get another internal implementation then?
If the developers prefer to do the internal implementation in Common
Lisp/Emacs Lisp rather than C/Emacs lisp and have
easier access to expose some libraries then that is another thing.
So when people talk about Emacs Lisp transitioning to Common Lisp,
please specify exactly what you want.
Exactly my thoughts. My fear is that this supposed transition to Common Lisp with fragment the emacs user base.. some will stick with elisp and some will move over to CL. Elisp is working very well for configs and packages. We should rather stick with it and keep on growing the codebase in the same language.
(If Elisp is completely discarded, we will not have enough people to convert *all* existing cool packages discovered and yet to be discovered from elisp to CL.)
So it is a lose-lose situation whether Elisp and CL co-exist or even if CL completely replaces Elisp.