> > I thought that the point of creating `cl-lib.el' was to give people a
> > library of the most-used CL constructs and still let them avoid loading
> > all of `cl.el'. If we are, in effect, loading `cl-extra.el' now nearly
> > by default then what's the point of separating out `cl-lib.el'?
>
> AFAIK, the point of cl-lib is to have the CL constructs in a separate
> namespace, so that loading cl-lib doesn't change the semantics of
> existing code that might not expect it (unlike cl.el).
What part of `cl.el' changes the semantics of existing [non-cl.el]
code?
Loading cl.el modifies the observable behavior of dolist. For example, insert the following into /tmp/dolist.el:
;;; -*- lexical-binding: t; -*-
(eval-when-compile (require 'cl-lib))
(message "Without cl.el")
(cl-dolist (i '(1 2 3))
(dolist (j '(a b c))
(message "i = %s, j = %s" i j)
(when (= i 2) (cl-return))))
(message "\nWith cl.el")
(eval-when-compile (require 'cl))
(cl-dolist (i '(1 2 3))
(dolist (j '(a b c))
(message "i = %s, j = %s" i j)
(when (= i 2) (cl-return))))
And then run:
$ emacs -Q -batch -l /tmp/dolist.el
Without cl.el
i = 1, j = a
i = 1, j = b
i = 1, j = c
i = 2, j = a
With cl.el
i = 1, j = a
i = 1, j = b
i = 1, j = c
i = 2, j = a
i = 3, j = a
i = 3, j = b
i = 3, j = c