41

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.

DavidRR
  • 18,291
  • 25
  • 109
  • 191
Cheeso
  • 189,189
  • 101
  • 473
  • 713

5 Answers5

28

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.

kdb
  • 4,098
  • 26
  • 49
  • This is interesting: ```cl-lib.el:73:1:Warning: cl package required at runtime``` while installing cl-lib. – boatcoder Feb 27 '15 at 20:57
  • 1
    It's likely you want to read the current doc for this functionality - http://www.gnu.org/software/emacs/manual/html_mono/cl.html – Ben Hyde Sep 20 '15 at 14:27
28

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

Vladimir Panteleev
  • 24,651
  • 6
  • 70
  • 114
Oleg Pavliv
  • 20,462
  • 7
  • 59
  • 75
  • Thanks for posting David's essay. I for one hope the cl policy will change in the future. – Joseph Gay Feb 16 '11 at 20:48
  • 1
    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. – Cheeso Feb 17 '11 at 00:23
  • I think it was kinda holy war between different dialects of Lisp. – Oleg Pavliv Feb 17 '11 at 06:20
  • 5
    FYI, I was just looking at some code which explicitly avoids this warning with `(eval-when-compile (require 'cl))`. – phils Feb 19 '11 at 02:23
  • Thanks phils for mentioning this – Oleg Pavliv Feb 20 '11 at 12:06
  • 1
    @phils: `(eval-when-compile (require 'cl))` will only work if the cl feature you need is in a macro. – Michael Hoffman Jul 13 '12 at 01:15
  • @Cheeso Xah Lee wrote another essay, [Controversy of Common Lisp Package in Emacs Lisp](http://xahlee.blogspot.com/2012/06/controversy-of-common-lisp-package-in.html). 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. – Michael Hoffman Jul 13 '12 at 01:18
  • 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. – Oleg Pavliv Jul 13 '12 at 13:04
  • 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? – Brian Z Feb 25 '15 at 10:53
  • @Brian Z Yes, you're right. In your case it's not useful information – Oleg Pavliv Feb 25 '15 at 12:56
  • 2
    Unfortunately link rot has gotten to the article in the answer. – boatcoder Feb 27 '15 at 20:55
  • Archive.org is our friend, and the enemy of linkrot: https://web.archive.org/web/20141203143357/http://dto.github.io/notebook/require-cl.html – Ben Hyde Sep 20 '15 at 14:05
  • @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](http://ergoemacs.org/emacs/elisp_common_lisp_in_emacs.html) – Androclus Aug 19 '20 at 17:18
  • 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. – pilgix Oct 04 '21 at 17:40
15

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.

Bernard Hurley
  • 356
  • 4
  • 6
  • I keep getting this debug error due to this : https://gist.github.com/avatar-lavventura/47792d4e5316a0b530c9ef2be1060aca – alper Aug 17 '20 at 17:00
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.

JSON
  • 4,487
  • 22
  • 26
1

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

Tim Johnson
  • 11
  • 2