Re: Lisp files that load cl-lib in problematical ways

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: bjorn.bidar@thaodan.de, stefankangas@gmail.com,
>       gregory@heytings.org, emacs-devel@gnu.org
> Date: Thu, 26 Oct 2023 22:12:18 -0400
> 
>   > How is cl-lib different from any other package that is extremely
>   > likely to be loaded close to a beginning of a production session?
> 
> I think that is the crucial question -- it shows the deep difference.
> 
> Most packages do a specific kind of job and have just a few entry
> points that relate to that job.  Consider sendmail.el, for instance.
> It Has commands to initialize a message and to send it, and some
> relating to editing one.  Most of the package is internals
> that you wouldn't need to know about in order to _use_ sendmail.
> 
> CL makes a big contrast with that. It is mainly entry points.  And
> many of these entry points try to be as multi-purpose as possible.

We have a lot of the CL variety as well.  Look at lisp/emacs-lisp/
directory: it is full of such "entry-point-only" packages, and most of
them aren't preloaded, they load on demand.  That's typical of any
Lisp package that provides infrastructure rather than applications,
like sendmail.el does.  cl-lib is one of those infrastructure
packages, but it isn't the only one, far from that.  We take care not
to preload such infrastructure packages unless they are needed by the
code which runs at build time, or are needed at startup.

So I again say: cl-lib is not different from any other infrastructure
package that is likely to be loaded because some Lisp program needs to
use it.

> This is why I'm concered with how many packages use CL, but not
> concerned with how many use sendmail.el.

Are you concerned with any of the following?

  easy-mmode.el
  eieio.el
  generic.el
  icons.el
  let-alist.el
  map.el
  rx.el
  subr-x.el
  unsafep.el
  warnings.el

They are all of the same nature: they provide utility functions to be
used by Lisp programs.