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

[Gerd Möllmann]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Gerd Möllmann <gerd.moellmann@gmail.com>
>> Cc: joaotavora@gmail.com,  michael_heerdegen@web.de,  emacs-devel@gnu.org
>> Date: Sun, 12 Nov 2023 07:59:13 +0100
>>
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>> >> Seq is 10 years in Emacs
>> >
>> > It is preloaded only since a little more than a year ago.
>>
>> You're saying that the real promotion of seq is only a year old?
>
> Yes.
>
>> And that things will "improve" once the promotion picks up speed?
>
> No.  I'm saying that we are still very far from a point where we have
> enough data to decide whether that year-old decision was wrong or not.
> Whether we see an improvement or not, time will say.

I think here's once difference in our thinking: One of my main critiques
does not depend on time. Please see below

>> >> its polymorphism is unused in the tree.
>> >
>> > Searching for seq-* in the tree brings more than 590 hits in more than
>> > 170 Lisp files.
>>
>> And? The polymorphism isn't used.
>
> Then I guess I don't understand what you mean by "polymorphism".

C'mon :-)

This sub-thread started, when I told why I'm not using seq and will not.
https://lists.gnu.org/archive/html/emacs-devel/2023-11/msg00122.html
I said this (this is all I wrote):

  The reason I will not use seq.el or map.el in the forseeable future is
  quite simple: I haven't ever needed an abstraction over sequence types
  using generic functions, and I never have CPU cycles to give away for
  free.

Neither you nor Richard ever addressed the question why this
polymorphism is needed or even a Good Thing. Richard even read seq.el
and even had his first exposure to pcase etc., but more than pondering
if one could make generic function calls faster was not the result.

>> >> Joao showed that it's slow.
>> >
>> > No, he didn't.
>>
>> Aha.
>
> No, really.  What he showed is that seq.el is in most (though not all)
> cases _slower_ than the corresponding cl-lib functions.  Sometimes
> much slower, sometimes slightly slower (and in at least one case
> faster).  But that doesn't mean seq.el is "slow", enough to make its
> use nonsensical.  Because why should we care that some call takes 2
> usec instead of just 0.5 usec? both are negligible.  The difference
> will only become visible if someone needs to call these in a very
> tight loop with a very large number of iterations.
>
> IOW, "slower" is not the same as "slow".  If we cared about "slow", we
> would have implemented everything in C.  We didn't because we have
> "other considerations", which are important to us and outweigh "slow"
> when "slow" is "fast enough".  Exactly like in the case of seq.el vs
> cl-lib.  Those "other considerations" in the latter case were
> abundantly described and explained up-thread, so I'm sure you know
> what they are, even though you disagree.

I actually got your intention when I wrote aha.

>
>> I've lost hope to hear something concrete a while ago.
>
> Same here, sadly.

Aha.

I doubt that your, and Richard's, intention is to really communicate
over these issues. It has already been decided by Richard and you,
right? The rest is rabulistic. Slow is fast enough, time will show,
maintainers think this or that, it's preloaded, it's not concrete, what
is polymorphism, and so on, and so on. Conspiracy theory is still missing.