Controversy of Common Lisp Package in Emacs Lisp

By Xah Lee. Date:

For you emacs lisp coders, there's controversy in using the cl package (require 'cl). This page is my introduction about the issue, with opinions from emacs developers.

First, here's what the official manual (info "(cl) Top") says about it:

   *Please note:* the "CL" functions are not standard parts of the
Emacs Lisp name space, so it is legitimate for users to define them
with other, conflicting meanings.  To avoid conflicting with those user
activities, we have a policy that packages installed in Emacs must not
load "CL" at run time.  (It is ok for them to load "CL" at compile time
only, with `eval-when-compile', and use the macros it provides.)  If
you are writing packages that you plan to distribute and invite
widespread use for, you might want to observe the same rule.

What that means is this: don't use (require 'cl) in your package. But if you want to use it, do it like this: (eval-when-compile (require 'cl)). This means, loading cl package is officially sanctioned by GNU only if your package is to be byte-compiled.

However, that doesn't seem to be the whole story. Eric Schulte (co-author of Org-babel) says:

http://lists.gnu.org/archive/html/emacs-devel/2012-02/msg00279.html

Eric Schulte wrote:

The above only applies to *macros* which are expanded at compile time. The expanded macros leave no reference to cl in the resulting compiled code. On the contrary cl functions (even in compiled code) when called at runtime still require cl to be loaded and available at runtime.

while discussing with a friend (Jon Snader) today, we broached on the controversy of CL package.

Common Lisp Compatibility Layer for Emacs Lisp?

The CL package is often thought of as a package that make emacs lisp compatible with Common Lisp. That is not exactly the case.

Stefan Monnier [http://www.iro.umontreal.ca/~monnier/] (one of the two current emacs dev leader) explains:

http://lists.gnu.org/archive/html/emacs-devel/2012-02/msg00202.html

From: Stefan Monnier
Date: Mon, 06 Feb 2012 16:08:56 -0500

Elisp is not Common-Lisp. CL does try to provide some CL-style functionality, but indeed it has some rough edges in this regard. It is much better to look at it as a handy toolbox, whose design was inspired by the experience of Common-Lisp, than to look at it as a “Common-Lisp compatibility layer”.

The points you raise sound like bugs indeed. We welcome patches to fix them, but I personally won't spend much time tracking those bugs down, because my experience with this part of CL is that it's not always easy to dig into it (it's *very* lightly commented for one, and parts of it are fundamentally broken).

Stefan Monnier is a professor, research on strongly typed languages.

Why Some Emacs Lisp Programers Don't Like CL Package

The GNU emacs dev list i scan occasionally, and this hot topic was debated now and then.

There are strong supporters in both camps.

Summary of pro-CL:

Summary of anti-CL:

The reason for CL package reservation does not seem to be definite. Some veterans have said that it's simply due to some GNU emacs dev don't like CL thru the ages. RMS being the major one. Stefan Monnier, one of the current emacs dev leader, also seem to be reserved about CL.

Lars Magne Ingebrigtsen (author of Gnus newsgroup reader and Gmane site.)

http://lists.gnu.org/archive/html/emacs-devel/2012-02/msg00297.html 
From: Lars Ingebrigtsen
Subject: Re: CL package serious deficiencies
Date: Wed, 08 Feb 2012 23:28:03 +0100
│ I've never understood what's wrong with including cl.el, nor why the
│ byte-compiler should warn specially about it, any more than it warns
│ about any other package.

Since the beginning of time, the Emacs maintainer (whoever they were at the time) just hasn't liked Common Lisp. The stated rationale for not “allowing” cl.el usage has shifted around a lot over the years, though. (“It's too big run-time-wise”, “we're going to reimplement Emacs in Scheme”, and now “the manual will be too big” and “it uses the wrong prefix”.)

Meanwhile, most of the people who program Emacs Lisp daily (i.e., people like me) have always been in favour of including it. Who doesn't want `incf'? `plusp'? `delete-if-not'? `position'? So you get all these hundreds of reimplementations of all these necessary functions, only spread over all the different packages.

Stephen J Turnbull (a XEmacs leader)

http://lists.gnu.org/archive/html/emacs-devel/2012-02/msg00259.html 
From: Stephen J. Turnbull
Subject: Re: CL package serious deficiencies
Date: Wed, 08 Feb 2012 11:07:02 +0900
Nix writes:
 │ (FWIW, the *last* time I asked about this, many years ago, I was told
 │ that runtime use of cl was out of the question because it used too much
 │ memory. I presume that this argument is obsolete ☺ )

The feeling I get is that some senior Emacs developers simply rather dislike Common Lisp, think that the programming style it encourages sucks, and don't want to see it in code they work on frequently.

Ah, the sweet smell of “technical differences” in the design fog….

Real Reason for/against CL

From what i see, i guess the divide is basically like this:

For those who have done Common Lisp programing, clearly it should be included. But for Scheme fans, they don't want CL encroach elisp, rather prefer C implementation for really useful functions, or wait for the scheme implementation of elisp.

According to the header file, CL package is written by Dave Gillespie, as early as 1993, and was a rewrite of Cesar Quiroz's original cl.el package of December 1986. Dave Gillespie is also the author of emacs's calc.

Pro CL Excerpts from Emacs Dev

http://lists.gnu.org/archive/html/emacs-devel/2012-02/msg00227.html

Nix wrote:

I've never understood what's wrong with including cl.el, nor why the byte-compiler should warn specially about it, any more than it warns about any other package. XEmacs has had cl.el in the dumped set for absolutely ages and it has caused zero problems as far as I know.

John Wiegley, author of eshell:

http://lists.gnu.org/archive/html/emacs-devel/2012-02/msg00337.html 
From: John Wiegley
Date: Thu, 09 Feb 2012 15:09:47 -1000

Lars Ingebrigtsen writes:

│ Meanwhile, most of the people who program Emacs Lisp daily (i.e., people
│ like me) have always been in favour of including it.  Who doesn't want
│ `incf'?  `plusp'?  `delete-if-not'?  `position'?  So you get all these
│ hundreds of reimplementations of all these necessary functions, only spread
│ over all the different packages.

I completely agree, Lars. Eshell had to reimplement several functions that I knew were in cl.el, simply because of this restriction.

Some of the things in cl.el -- such as loop, defun*, and a few others -- I could care less about. These are more about coding in a CL style as opposed to the equivalent Elisp style. But other functions that concern basic algorithms, such as `reduce', I really would like to see dumped into Emacs core. *With* keywords (they make some usages very clear and easy to read).

I'm also one of those who has had cl.el required into my Emacs for over ten years now, and I've never once encountered a hiccup because of it. It's time has come!

Daniel Colascione (co-author of javascript-mode):

Daniel Colascione wrote (http://lists.gnu.org/archive/html/emacs-devel/2012-02/msg00240.html):

The latest objection is that dumping CL would Emacs would increase the size of the printed and bound Emacs Lisp Reference Manual from the FSF. I find this objection unconvincing because it applies to _any_ new feature, and I don't think we're against adding new features to Emacs.

Anti CL Excerpts from Emacs Dev

http://lists.gnu.org/archive/html/emacs-devel/2012-06/msg00056.html 
From: Richard Stallman
Subject: Re: Using cl in rst.el and elsewhere
Date: Sun, 03 Jun 2012 14:30:49 -0400
 │ We are already using CLOS (in the form of EIEIO), so the elisp lib cl.el
 │ really has been unfairly treated for such a long time because it was put
 │ into emacs too ahead of time and because of rms's dislike of CL (the
                                               ^^^^^^^^^^^^^^^^^^^
 │ language).

 Ah, I see. Indeed this whole things really smells a lot like a
 political decision like this.

That is erroneous as well as arrogant and nasty.

Some of my decisions about GNU Emacs are political -- derived from the political purpose of GNU Emacs and of GNU as a whole. If you think that is a bad thing, you may be in the wrong place.

However, my decision not to include the cl functions in the normal Emacs name space is simply technical. So is my decision not to make the CL definition of functions such as `member' the standard definitions in GNU Emacs.

My technical design decisions are based on my ideas of what is technically better or worse, as are everyone's technical design decisions.

http://lists.gnu.org/archive/html/emacs-devel/2012-02/msg00272.html

Richard Stallman wrote:

The point is that it would make the CL functions part of the standard Emacs namespace. That has two problems:

* CL is ugly. It is not well integrated with the rest of Emacs Lisp.

* We would have to document the CL functions in the manual, which is a big increase in the size. It is not that that is totally intolerable, it's that the benefit is not worth the burden.

…

Maybe we are miscommunicating. The ugliness I am talking about is in the specs of these functions, not the implementation. The specs of the CL functions don't fit in well with Emacs Lisp. This isn't something that could be fixed with more work on the code.

Alan Mackenzie (maintainer of cc-mode):

http://lists.gnu.org/archive/html/emacs-devel/2012-02/msg00241.html 
From: Alan Mackenzie
Subject: Re: CL package serious deficiencies
Date: Tue, 7 Feb 2012 22:16:53 +0000

Hi, Daniel.

On Tue, Feb 07, 2012 at 01:34:06PM -0800, Daniel Colascione wrote:
│ On 2/7/12 1:23 PM, Nix wrote:
│ │ (FWIW, the *last* time I asked about this, many years ago, I was told
│ │ that runtime use of cl was out of the question because it used too much
│ │ memory. I presume that this argument is obsolete ☺ )

│ I've long been an advocate of dumping cl with Emacs; XEmacs does so
│ without problems.

The CC Mode test suite (in particular, 000tests.el, available from the CC Mode site at SourceForge), uses cl at run time. It's been getting wierd “can't happen” errors for years: some error starts appearing, repeatedly, then after some unrelated change in CC Mode, stops appearing. Then another wierd error starts happening, then stops. This has been going on for years. The current error, which has been happening for ~6 months, is:

    Testing awk-face-1.awk (fonts)  Buffer is read-only: #<buffer *cc-test*>

. This doesn't happen with XEmacs (though other errors do).

I believe that the cl files are somehow responsible; Barry Warsaw (who originally wrote 000tests.el) was and is a competent hacker.

│ CLisms simply result in cleaner, smaller code than one can write using
│ nothing but elisp primitives.

│ The latest objection is that dumping CL would Emacs would increase the
│ size of the printed and bound Emacs Lisp Reference Manual from the
│ FSF. I find this objection unconvincing because it applies to _any_ new
│ feature, and I don't think we're against adding new features to Emacs.

I'd recommend not changing the policy on CL until it acquires a rigorous test suite. I don't really trust it beyond use at byte-compile time.

For some quotation of famous lispers who don't like Common Lisp, see: Common Lisp Sucks.

Emacs Lisp Misc Essays