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

[João Távora]

On Thu, Nov 16, 2023 at 2:36 PM Augusto Stoffel <arstoffel@gmail.com> wrote:
>
> On Thu, 16 Nov 2023 at 00:28, João Távora wrote:
>
> > I don't think you just skip the seq-do generic like that :-)
>
> Of course you don't.  This _is not_ a patch submission :-).
>
> What I'm pointing out is that the seq-doseq macro is probably the most
> consequential bit regarding performance.  If you use a mapc and closures
> where you could use a simple dolist, performance will obviously suffer.
>
> There exist extensible macros in Emacs (such as pcase), so adding some
> kind dynamic dispatch for seq-doseq should be possible.  Barring that,
> one would have to define list-specific methods for 8 generic functions
> that use seq-doseq, which is also not unfeasible.
>
> > That breaks any sequence type based on lists.  This is exactly the
> > problem I was raising with too-many-generic interfaces, btw.
>
> Good point.  IMO you just can't have both lists and "types based on
> lists" to work together properly; if we defined a method for
> seq-difference on lists, the issue would be the same (I guess that's the
> caveat you raised regarding Dmitri's patch).
>
> I don't see much appeal in user-defined seq types (as opposed to dealing
> uniformly with lists, vectors and strings, which is mildly useful).


User-defined sequences _are_ useful in certain problem domains.
Generators, streams, lazy sequences, these are all great things.

But in bread-and-butter Lisp (LISt Processing ;-) ) we don't
need them indeed.  And we should absolutely use the fastest
library we have.  seq.el can hardly  be it, even if you do that
shortcut (and effectively outlaw a big class of custom sequences,
presumably the thing seq.el is good at).

>   In
> any case, the user always has the options to wrap a struct or class
> around their custom list types.  So "sequence types based on lists"
> could just be disallowed (I suppose this was part of those long
> discussions, which I admit I didn't follow closely.)

Yes, exactly.  And sure yes, but in many cases the lingering
performance overhead of generic functions still remains, unless
you go all the way to the entry point and break compatibility
there too.  See my latest benchmarks i sent in the Dmitry thread.

> > Try Dmitry's patch instead, the one containing seq-difference-3.
>
> That approach is fine, but it only addresses one function at a time.
> (If we go that way, I suggest starting by the most useful ones:
> seq-filter, seq-some and seq-reduce.)

Feel free to start your branch from feature/cl-lib-improvements
and keep posting benchmarks.

> As far as names are concerned, cl-remove-if-not is uglier than
> seq-filter.

Ha, this one haunts me from the early 2000's

"filter" for me personally has, for as long as I remember, been
a pain in the brain.  I can never tell if is is meant to keep
things that verify a predicate or throw away such things.  I
still can't, I always have to look it up.

like: "filtering coffee" leaves the bad stuff behind.
"filtering Yukon river water" leaves the good stuff behind (gold).

So while I have to agree that cl-remove-if-not is a pain to type,
it's very clear as to what it does when you read it.   Have long
argued it should have been called "keep-if" though.

> > cl-some vs seq-some
> > cl-every vs set-every-p
> > cl-set-difference vs seq-intersection
>
> cl-set-difference is an operation on lists, not sets...

So is seq-intersection.  Also not on sets.

> > What specific thing do you like in seq.el that you don't
> > find in the sequence functions of cl-lib.el?
> Like other people already said, it's more about what you _don't_ find in
> seq.  The seq API is much more straightforward than cl-lib's.

See my message to Dmitry.  You think the super-special
seq-remove-at-position is a good replacement for
the much more versatile cl-remove?  Bah.

But hey, if it weren't for the performance aspect  I would
absolutely surely 1000% not mind you using seq.el in
your code or in Emacs.

João