emacs-lisp/cl-*.el and requirement of cl

emacs-lisp/cl-*.el and requirement of cl

[Glenn Morris]

Does anyone know why emacs-lisp/cl-compat.el does this:

  ;; Require at load-time, but not when compiling cl-compat.
  (or (featurep 'cl) (require 'cl))

rather than just a simple "(require 'cl)"?

Similarly, cl-macs and cl-seq throw errors if loaded without cl being
loaded first. Is there any reason not to just make them require cl?
I know just doing it naively can lead to a recursive require, but that
is easily worked around, eg:


*** cl.el	12 May 2008 01:45:41 -0000	1.63
--- cl.el	3 Jul 2008 21:29:27 -0000
***************
*** 632,648 ****
  
  ;; This goes here so that cl-macs can find it if it loads right now.
  (provide 'cl-19)     ; usage: (require 'cl-19 "cl")
  
  ;; Things to do after byte-compiler is loaded.
- ;; As a side effect, we cause cl-macs to be loaded when compiling, so
- ;; that the compiler-macros defined there will be present.
  
  (defvar cl-hacked-flag nil)
  (defun cl-hack-byte-compiler ()
!   (if (and (not cl-hacked-flag) (fboundp 'byte-compile-file-form))
!       (progn
! 	(setq cl-hacked-flag t)		; Do it first, to prevent recursion.
! 	(cl-compile-time-init))))	; In cl-macs.el.
  
  ;; Try it now in case the compiler has already been loaded.
  (cl-hack-byte-compiler)
--- 632,648 ----
  
  ;; This goes here so that cl-macs can find it if it loads right now.
  (provide 'cl-19)     ; usage: (require 'cl-19 "cl")
+ (provide 'cl)
  
  ;; Things to do after byte-compiler is loaded.
  
  (defvar cl-hacked-flag nil)
  (defun cl-hack-byte-compiler ()
!   (and (not cl-hacked-flag) (fboundp 'byte-compile-file-form)
!        (progn
!          (setq cl-hacked-flag t)  ; Do it first, to prevent recursion.
!          (load "cl-macs" nil t)
!          (run-hooks 'cl-hack-bytecomp-hook))))
  
  ;; Try it now in case the compiler has already been loaded.
  (cl-hack-byte-compiler)

Re: emacs-lisp/cl-*.el and requirement of cl

[Miles Bader]

Glenn Morris <rgm@gnu.org> writes:
> Similarly, cl-macs and cl-seq throw errors if loaded without cl being
> loaded first.

Why would you want to?  AFAIK, those filenames are internal
implementation details of cl and not intended to be exported.
`cl' is the publicly exported interface.

> Is there any reason not to just make them require cl?

What would be the advantage over simply having users require cl
(presumably they already do so, as not doing so currently results in an
error)?

-Miles

-- 
Bacchus, n. A convenient deity invented by the ancients as an excuse for
getting drunk.