In Emacs, what does this error mean? "Warning: cl package required at runtime"

Question

I am byte-compiling a module. It gives me this warning:

 Warning: cl package required at runtime

Why is this a warning? I am well aware that I am using the cl package. In fact there is a (require 'cl) statement in the module.

Is there something wrong with using the cl stuff?

If so, is there a list of published workarounds? The main things I use are mapcan and delete-duplicates.

Spector

Answer 1

The reason of this warning is a GNU policy which does not want a package cl to be used in Elisp. But it would be foolish as well to prohibit it completely. So they decided to show a warning.

You can find more information here

Murmansk

Thanks for posting David's essay. I for one hope the cl policy will change in the future. – Leaguer

Thanks for posting this, but I still don't get why GNU does not want cl.el to be used in Elisp. I read it and re-read it, but I didn't see a justification. Am I the only one who is confused? I guess I'll look into removing the dependency on cl.el, to eliminate the warning, but I'd still like to know why I need to do this. – Spector

I think it was kinda holy war between different dialects of Lisp. – Murmansk

FYI, I was just looking at some code which explicitly avoids this warning with (eval-when-compile (require 'cl)). – Obstacle

Thanks phils for mentioning this – Murmansk

@phils: (eval-when-compile (require 'cl)) will only work if the cl feature you need is in a macro. – Kimberelykimberlee

@Spector Xah Lee wrote another essay, Controversy of Common Lisp Package in Emacs Lisp. Given the quotation from RMS, it seems one of the reasons CL is not included is that many parts of it just do not fit consistently with the rest of Emacs. RMS calls it "ugly." I do find this limitation frustrating when I'm trying to use other functions, though, like some and every, which could fit into Elisp just fine in my opinion. – Kimberelykimberlee

Thanks Michael, it's a useful article. Well, the biggest problem of Lisp (which is a beautiful language) is a lack of standard so that only one TRUE Lisp exist. – Murmansk

Am I correct in understanding that if a package does not seem to be installing correctly, and that the only error I get during the installation is this one, it's not actually telling me anything useful? – Touchhole

@Brian Z Yes, you're right. In your case it's not useful information – Murmansk

Unfortunately link rot has gotten to the article in the answer. – Adorne

Archive.org is our friend, and the enemy of linkrot: web.archive.org/web/20141203143357/http://dto.github.io/… – Jukebox

@MichaelHoffman Thank you (8 years later) for that reference. And for anyone still arriving here via search engine: Xah Lee's 'Controversy' page on blogspot.com has for some time now been moved to http://ergoemacs.org/emacs/elisp_common_lisp_in_emacs.html – Lidia

To get rid of the warning, on MacOS (11.6), (setq byte-compile-warnings '(cl-functions)) only worked if put in early-init.el. Since it didn't exist in my system, I created it as ~/.emacs.d/early-init.el. It worked okay then. – Centrosphere

Answer 2

Just in case someone reads this on his quest for proper use of cl: The methods described here are now deprecated.

As least as of emacs 24, instead of cl you should use cl-lib or, if the macros suffice, cl-macs. These are new versions of cl that work with a clean namespace. E.g. instead of defun* you have cl-defun.

The old cl-package now is only for backward-compatibility and shouldn't be used in new code.

Obliteration

This is interesting: cl-lib.el:73:1:Warning: cl package required at runtime while installing cl-lib. – Adorne

It's likely you want to read the current doc for this functionality - gnu.org/software/emacs/manual/html_mono/cl.html – Jukebox

Answer 3

There are namespace clashes between Elisp and Common Lisp but the cl package gets round them by appending an asterisk to the repeated names. For instance it implements the Common Lisp version of defun but calls it defun*. The upshot is that there are no namespaces clashes between cl and Elisp and it is quite safe to (require 'cl).

If you want to get rid of the silly warning, customize the variable byte-compiler-warnings.[1] This will turn off the warning when you compile the code. If you distribute the code the warning will probably came back when someone else compiles it. If you don't want this to happen use the code:

(with-no-warnings
   (require 'cl))

You can stop the byte compiler warning about any Lisp form in a similar way.[2] It's probably a not good idea in general, but you may be able to justify it in this case.

The code:

(eval-when-compile
   (require 'cl))

will get rid of the warning, but you will only be able to use the macros from the package if you do this. Macros are evaluated at compile time and Elisp does not need to know about them at run time. If you only use the macros from any package, not just cl, then it is a good idea to use eval-when-compile as it will stop unnecessary packages loading at run time, both saving memory and making the code faster. But it seems to me that it's a misuse of the function to use it just to avoid a warning. And, of course, if you do want to use any of the functions from cl, you can't use eval-when-compile anyway.

[1] You may need to add (require 'bytecomp) to your .emacs file to get access to this variable.

[2] In theory, anyway, but there's a bug in with-no-warnings that means it doesn't supress some warnings about lexical variables.

Aminta

I keep getting this debug error due to this : gist.github.com/avatar-lavventura/… – Fourpenny

Answer 4

Common Lisp has lots of namespace clashes with elisp, often the functions seem to do the same thing, but differ in some subtle detail. Mixing the two is a risk that is best not done behind the user's back. For this reason, most of the more useful functions in cl.el are defined as macros, so that cl.el can be required at compile time only, and the macros will then only affect the code that uses them in future sessions of Emacs.

Orthotropous

Answer 5

I wasn't able to suppress this message after reading the comments before mine.

However, I received the following instruction from a kind person on the GNU emacs mailing list:

Require cl-lib, and then change the call to use cl-remove-if-not, instead of remove-if-not.

Which proved to be the remedy.

In sum: by 'requiring cl-lib, one must also change the name of the function/macro call.

HTH....

Lithotrity