CODEWITHSUNDEEP
emacslispcommon-lisp
Cheeso
Cheeso

Reputation: 192467

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

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.

Upvotes: 41

Views: 12161

Answers (5)

Oleg Pavliv
Oleg Pavliv

Reputation: 21162

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

Upvotes: 28

Tim Johnson
Tim Johnson

Reputation: 11

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....

Upvotes: 1

kdb
kdb

Reputation: 4416

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.

Upvotes: 28

Bernard Hurley
Bernard Hurley

Reputation: 366

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.

Upvotes: 15

JSON
JSON

Reputation: 4606

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.

Upvotes: 4

Related Questions