Drew Adams <drew.adams@oracle.com> schrieb am Di., 7. Feb. 2017 um
03:23 Uhr:

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