bug#57079: 29.0.50; Performance of seq-uniq is not very good

[Michael Heerdegen <michael_heerdegen@web.de>]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> > [...]  Once we said we don't want to extend CL too much because it
> > should be compatible with Common Lisp.
>
> We've dropped that argument a long time ago -- it's free-for-all-time in
> cl-lib.el.

Are we going to merge (or cherry pick) stuff from seq.el to cl-lib?
Probably not, so let's disregard the idea that cl-lib will ever be a
complete replacement for seq.el stuff.

> They're both fully baked, but use different design philosophies,
> catering to different audiences.  Of course I think that all seq.el
> functions should have :key...  and :test-not and :start and :from-end,
> but I come from a CL background.

I don't think I get it/buy it.  Could you explain (in theory, a yes/no
question) why we should not support that use case in `seq-uniq' without
saying the word "CL", and if you say "design", without comparing with
the design of CL?

If you can't: seq.el has lots of overlaps with other parts of Emacs.
What is so special about CL that an overlap is not acceptable?  Or what
is special about this task that it is not possible to handle it in
several places?

Please remember: I don't think in the term of "key functions", and I
don't want to introduce something like that to other seq.el functions,
so here is no argument.

I'll stop asking after this Email because we are going in circles - but
so far I just don't find your argumentation conclusive.

Actually, this `seq-uniq' function is a logical part of the yet-to-write
set.el library.  The task/semantics is: Find a subset containing exactly
one representative from each class of the elements of a given set.  But
I guess this library would also not be allowed to solve this task?  Why
do we add and develop them then at all?  Wouldn't it be better to
improve and develop cl-lib further instead then?  Serious question.

TIA,

Michael.