bug#21464: 25.0.50; [cc-langs] void-function cadar

[Stefan Monnier <monnier@iro.umontreal.ca>]

>> Using cl-lib instead of cl would solve such issues easily since we could
>> use cl-cadar and (require 'cl-lib) at run-time instead of only requiring
>> cl at compile-time.
> CC Mode in Emacs (as opposed to XEmacs) has been using cl-lib instead of
> cl for some weeks, now.

By "using cl-lib" I mean "assume cl-lib is always available" and
"don't use cl anymore anywhere".

That's a lot more convenient than the current testing and using various
macro wrappers depending on the circumstance and it'd let you use
any CL functions and macros anywhere any time.

> It would be bound to clash with a cl-lib in Emacs

Your assumptions are faulty, I think.

You'd put it in a subdirectory, say "cc-cl-lib" (so it's not in
load-path by default) and in cc-compat.el you'd do something like:

  (unless (featurep 'cl-lib)
    (unless (locate-library "cl-lib")
      (add-to-list 'load-path
                   (expand-file-name "cc-cl-lib"
                                     (file-name-directory load-file-name))))
    (require 'cl-lib))

or

  (unless (featurep 'cl-lib)
    (require 'cl-lib
             (unless (locate-library "cl-lib")
               (expand-file-name "cc-cl-lib/cl-lib"
                                 (file-name-directory load-file-name)))))

> (or a cl in XEmacs) somehow.

The cl-lib.el I'm talking about is the one in GNU ELPA, which is
basically loads cl.el and then adds a whle bunch of aliases under the
new "cl-*" namespace.  So no, it doesn't clash with cl.el, instead it
relies on it.

> I'm marking this bug as closed.

Indeed, thanks,


        Stefan