Controversy of Common Lisp Package in Emacs Lisp - comp.emacs

The old Google Groups will be going away soon, but your browser is incompatible with the new version.

« Groups Home

comp.emacs

Discussions

+ new post

About this group

Subscribe to this group

This is a Usenet group - learn more

Controversy of Common Lisp Package in Emacs Lisp

Options

1 message - Collapse all

Xah Lee

View profile

More options Jul 6 2012, 11:20 am

Newsgroups: comp.lang.lisp, comp.emacs

From: Xah Lee <xah...@gmail.com>

Date: Fri, 6 Jul 2012 08:20:00 -0700 (PDT)

Subject: Controversy of Common Lisp Package in Emacs Lisp

Print | Individual message | Show original | Report this message | Find messages by this author

〈Controversy of Common Lisp Package in Emacs Lisp〉
http://ergoemacs.org/emacs/elisp_common_lisp_in_emacs.html

probably of interest to many of you.
plain text version follows.
---------------------------------------------

[1]Emacs Lisp Tutorial

Controversy of Common Lisp Package in Emacs Lisp

Xah Lee, 2012-06-13

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. [2]Eric Schulte
(co-author of Org-babel) says:

[3]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 ([4]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.

[5]Stefan Monnier (one of the two current emacs dev leader)
explains:

[6]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).

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:
* Many major packages use it. Practically, there isn't any
problem.
* XEmacs has been using it without any problems.
* It's practical. Just use it. This is better than every
developer re-invent the wheel. Especially useful are list-manipulation
functions (e.g. checking member existence, deleting members, union,
intersection, reduce, …).

Summary of anti-CL:
* Common Lisp the language is ugly.
* CL package implementation has many issues (e.g. inefficiency,
incorrect behavior)
* CL package as it is encroaches elisp namespace. (in emacs 24.1,
some of these are moved into “cl-*” namespace.)
* Embracing CL package burdens documentation for elisp. (RMS)

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. (he's functional lang researcher academic)

[7]Lars Magne Ingebrigtsen (author of [8]Gnus newsgroup reader and
[9]Gmane site.)

[10]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.

[11]Stephen J Turnbull (a XEmacs leader)

[12]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 [13]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

[14]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.

[15]John Wiegley, author of [16]eshell:

[17]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!

[18]Daniel Colascione (co-author of javascript-mode):

Daniel Colascione wrote ([19]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

[20]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.

[21]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.

[22]Alan Mackenzie (maintainer of cc-mode):

[23]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.

[24]✍

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

* [26]Emacs Lisp Function Frequency
* [27]How Purely Nested Notation Limits The Language's Utility
* [28]Fundamental Problems of Lisp

[29]blog comments powered by Disqus ∑ [30]ErgoEmacs Home

References

End of messages

« Back to Discussions

« Newer topic

Older topic »

Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy

Account Options