[implementations-list] GNU Emacs policy that says packages must not use cl.el at runtime (was: viper-in-more-modes still needs ...)

Tue Feb 9 17:54:28 CET 2010

On Tue, Feb 09, 2010 at 01:42:13AM -0500, Jason Spiro wrote:
> On Sun, Jan 3, 2010 at 9:58 PM, Stephen Bach <sjbach at sjbach.com> wrote:
> > On Sat, Jan 02, 2010 at 10:40:10PM -0500, Jason Spiro wrote:
> >> >  3. GNU Emacs enforces the backward policy that packages must not use
> >> >     cl.el Common Lisp extensions at runtime.  This kind of restriction
> >> >     is another enemy to development momentum; if it's expedient to
> >> >     Vegard or another developer to leverage a standard library, they
> >> >     should be empowered to do so.
> >>
> >> But John J. Foerch said in his email of Wed, Oct 3, 2007 at 11:00 PM
> >> at http://my-trac.assembla.com/vimpulse/ticket/2 that there are cl.el
> >> macros that override core Emacs functions.  Do you still stand by your
> >> assertion?
> >
> > Yes.  cl.el's version of push subsumes GNU Emacs' standard push - it's
> > not dangerous.  Almost anyone who uses Emacs extensively will load cl.el
> > as part of their configuration.  XEmacs loads it by default.
> 
> What reason does the GNU Emacs team give for this policy?  If it turns
> out to be a flimsy reason, then perhaps you or Vegard could get the
> policy changed if you wanted to.  :)
> 

Two cents: I think the cl.el policy is smart, actually.  Common Lisp is a
rather crufty language --- a design of "politics" rather than a design of
"art" as the old cliché about CL vs. Scheme goes.  For example, it would
be hard to make the case that generalized variables belong in Elisp, as
they are unnecessary, redundant, and complex.  Don't get me wrong, I love
Common Lisp for what it is, on its own terms, but I would not hold it up
as some kind of ideal for the future improvement of Emacs Lisp.  What I
would advocate for (and have) is to add specific useful features to Elisp
in the specific areas where Elisp is lacking.  For a single example, Elisp
has no fold or reduce, and I have found need to write it myself on more
than on occasion.  Anyway, my basic point is that if you want to see Elisp
improved, there are more elegant languages than Common Lisp to use as your
model.

-- 
John Foerch