Re: What's missing in ELisp that makes people want to use cl-lib?

[João Távora]

On Sat, Nov 11, 2023 at 7:56 AM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: Michael Heerdegen <michael_heerdegen@web.de>
> > Date: Sat, 11 Nov 2023 07:01:39 +0100
> >
> > My goal would be like this:
> >
> >  - keep cl-lib available to it's current extent for end users
> >
> >  - try to get unnecessary cl-lib uses out of the code base
> >
> >  - make useful cl ideas available in the core language
>
> These are exactly our goals.  We've been doing this for years: that's
> how stuff like 'when', 'unless', 'push', 'pop', and others got into
> the core.
>
> IOW, the way to make some cl-lib functionality freely available in
> core is to have a similar or identical implementation in the likes of
> subr.el or seq.el, using our naming convention instead of cl-FOO.

I generally agree with the goal of bringing in cl-lib.el ideas into
core, but it must be said here that seq.el, despite being a sequence
processing library, should NOT be viewed as a drop-in replacement
for cl-lib.el counterparts

seq.el strength over cl-lib.el is that it is a generic sequence
processing library.  IMO it _should_ be used if there is the suspicion
that the sequences being in that data being processed by a given
function can be custom seq.el sequences.  Or when there is good
reason to suspect that one they might be such custom sequences.

I think that seq.el _should_ be used in those situations because
it expresses exactly this fact, so it becomes self-documenting.

I think the argument that Gerd is making in his economic
contributions is that very often seq.el is overkill.

For example, in its current form should _not_ be used when
there is certainty that the sequences are Lisp listsm because as I
showed elsewhere here, seq-some is significantly slower than
cl-some and cl-loop when processing lots of small lists.

Also, I know you don't like cl-loop but in terms of efficiency
it's sometimes a very good choice.  For example, processing
maintain list in order without it often requires a nreverse
at the end or even more code.  And the fact that cl-loop doesn't
need to do dispatching on different sequence types means it's
faster.  And less polymorphic of course, but sometimes you
simply don't _need_ polymorphism.

I do agree fully that writing

  (cl-loop for i in l do (foo i))

is kind of uncalled _in any situation_ if you can just write

  (dolist (i l) (foo j))

But when you need to process plists, for example, it becomes
very handy.  This construct, which does require knowing a bit
of the mini-language that is cl-loop,

  (cl-loop for (k v) on plist by #'cddr collect (cons k v))

is still the most concise way IMHO of processing a plist
for example.  Of course that is debatable.  Maybe you
prefer a raw while loop with some auxiliary variables, but
while that is more universal, it doesn't necessarily mean
it's more readable.  These are two different things that
people are mixing in here.  I would be on the fence if this example
would justify introducing cl-lib.el into a file or not.
Depends on how often this plist-processing business is needed.
Or whether there is a pair-sequence-processing util in seq.el
AND performance is not at stake.

And certainly we should not immediately shoot down a contribution
to the core without "batting an eyelid", as someone suggested
here, just because it doesn't fit a stylistic preference.

By the way, I also think Michael's idea of splitting up
cl-lib.el further into smaller bits is very good.

João