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

[Dmitry Gutov <dmitry@gutov.dev>]

On 15/11/2023 03:17, João Távora wrote:
> On Wed, Nov 15, 2023 at 1:07 AM João Távora <joaotavora@gmail.com> wrote:
> 
>> Not really.  Only if I use my seq in contexts where I need that
>> generic, and being second argument to seq-difference doesn't count.
>> So why should I bother implementing that when my code is working
>> fine today?
>>
>> But say I did that seq-do, then what is the seq-contains-p generic good
>> for then?
> 
> Let me answer that for you... It could be, maybe even likely, that the
> code was trying to get out of seq-do for some types of operation, because in
> the case of lazy lists, seq-do would mandate the list be completely expanded.
> 
> So, while the code works, you seq-difference-3 now calls seq-do on the
> second argument, and kills my laziness, naughty naughty.

Indeed, it might as well be that a type had a specialized fast 
implementation for seq-contains-p and doesn't have one for 
seq-contains-pred, and the switchover would tank the performance of its 
callers.

As long as the observable behavior stays the same (aside from 
performance), that seems fine. The type's author will need to implement 
seq-contains-pred. Hopefully such migrations will remain rare enough.

> Actually for this point to make sense, it doesn't even have to be
> a bizarre voodoo list.  The lazy list may just be expanded enough already
> for me to know in seq-contains-p that there's a given element
> there without having to call the generator for more list elements.
> 
> So seq-contains-p was indeed an optimization, in more or less
> the sense you described, which is now lost when you tried to optimize
> for bare Lisp sequences.

Right. The author will now need to optimize seq-contains-pred, getting 
even better performance than previously in return.