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

[Alan Mackenzie]

Hello, Eli.

On Thu, Oct 26, 2023 at 09:55:45 +0300, Eli Zaretskii wrote:
> > From: Richard Stallman <rms@gnu.org>
> > Cc: eliz@gnu.org, acm@muc.de, emacs-devel@gnu.org
> > Date: Wed, 25 Oct 2023 22:27:54 -0400

> >   > The only difference I see is that new version is harder to read, and
> >   > more prone to bugs (as you have to write the same code twice).

> > Do you frequently use the cl- facilities such as `cl-pushnew'?  If so,
> > that might explain why you didn't _see_ the extra complexity that
> > comes from calling `cl-pushnew'.  That extra complexity exists for
> > people who don't habitually use cl facilities, and not for those who
> > do habitually use them.

> I think the need to be familiar with the cl-lib and cl-macs
> functionalities is nowadays a requirement for any Emacs maintainer.

For me, that is not possible.  I simply don't have the brain power to
memorize such a morass of arbitrary, poorly named, poorly documented
stuff.  I am forever cursed by having to look up doc strings each time I
encounter these objects.  Maybe not things like cl-incf, but
monstrosities such as cl-labels just leave me groaning.  I frequently
spend, perhaps, half of my debugging time trying to understand what some
cl-* does rather than concentrating on the problem to be debugged.

> It can take time to familiarize oneself with them, but it isn't rocket
> science.

How many contributors are actually familiar with the bulk of cl-lib?
I suspect, very few indeed.  Maybe Stefan M.  The people who have written
strongly in favour of cl-lib over the last week or two have not been
those who spend lots of time maintaining others' code.

I further suspect that many contributions using cl-lib are from people
who know a small part of cl-lib, find the functionality intriguing, and
thus use it.  The trouble is, each such contributor knows a different
part of it, so in aggregate the part that an Emacs maintainer needs to
know (or continually to look up) is large.

Note that Common Lisp never took off as a popular language.  There must
be reasons for this.

> Btw, some of the cl-lib facilities should not be used in new code if
> they have equivalent implementations ins seq.el (which is nowadays
> preloaded) and in map.el.  cl-generic.el is also preloaded, so should
> be used in preference to the cl-lib alternatives.  And some frequently
> needed cl-lib functions were moved to cl-preloaded.el, and are also
> always available.

-- 
Alan Mackenzie (Nuremberg, Germany).