RE: Guile in Emacs

["Drew Adams" <drew.adams@oracle.com>]

> While I rather like CL, and much prefer it to Scheme, I don't 
> see why we need to consider either.  I don't see much wrong
> with elisp as it is. In my view it simply is not among the
> major limiting factors of Emacs.

FWIW, I agree. I don't see a need to change things fundamentally.

If some particular aspects of either CL or Scheme are considered desirable
individually, then we could move toward accommodating them (adopting/adapting).

Incremental evolution that way, in the normal Emacs base code (as opposed to
creating a parallel Scheme-based or CL-based Emacs), would help ensure that
non-core libraries, including 3rd-party libraries, kept pace. Emacs is not just
someone's term project.

The main and most important difference from Elisp, for both CL and Scheme, lies
in more robust support for lexical scoping. CL's approach to mixing lexical and
dynamic scoping would be a reasonable one for Emacs Lisp. We currently have
`lexical-let' and that's about all. Common Lisp goes much further toward taking
advantage of lexical scoping than we currently do in Emacs.

I might add that a better time to have considered this would have been 1985 or
1990, not 2010. ;-) When both CL and GNU Emacs were young would have been the
perfect time. Richard is not crazy about CL, and my guess is that that's the
reason we aren't as close to it now as we might be.

I do, BTW, agree with Richard that there is a lot in CL that Emacs does not
necessarily need. But the basic design of CL would not be a bad one for Emacs,
IMO.

I also suspect that if there were really much interest in moving in this
direction, then we would already have moved Emacs Lisp a little closer to CL. It
just hasn't happened.

It is also the case that Emacs would already have much more CL-like and
CL-somewhat-compatible code now if there were not so much push-back to using CL
functions at runtime. Don't get me wrong - I support the push-back.

My point is only that if you look at 3rd-party Emacs-Lisp libraries (not mine
;-)), especially by younger developers, you'll see widespread use of cl.el
functions. That's an indication that people would use CL constructs if they were
more solidly part of Emacs Lisp. The evolution toward more CL-ness would thus
partly take care of itself. The problem is that the foundation is shaky.