Re: Emacs Lisp's future

[Søren Pilgård]

On Fri, Oct 7, 2016 at 12:47 PM, Lars Brinkhoff <address@hidden> wrote:
> Now that we have new maintainers, I'd be curious to hear if they have
> any thoughs on this?  (See the original post for more information.)
>
> Stefan Monnier wrote two years ago:
>> I've had the opportunity to think a bit more about Emacs Lisp and its
>> possible evolution and I'm still not sure what to think about it.
>> [...]
>> I think that ideally, we'd want to stick to Elisp, or some evolution
>> thereof.  Sadly, I don't see how to evolve Elisp into Scheme: they are
>> closely related languages, but the differences are large enough that
>> it seems hard to reconcile them.
>>
>> The only standard language into which Elisp can evolve, AFAICT, is
>> Common Lisp.  [ Now some readers get disappointed, while some others
>> become excited.  ]  There are some incompatibilities between the two
>> languages, but I can imagine working them out over the years, or even
>> living with them without too much trouble, such that we could use
>> Common-Lisp libraries in Emacs.
>
>


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.