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

[Lars Ingebrigtsen <larsi@gnus.org>]

Michael Heerdegen <michael_heerdegen@web.de> writes:

>> I think we're into cl-lib.el territory then -- seq doesn't do KEY.
>
> It would make lots of uses much faster, call it as you like, don't think
> about how it's used in CL, it makes sense to add it as functionality to
> this function - that's the important part.  We can find a different
> interface if you prefer that, e.g. allow the test function to be
> (TEST F) or something like that.

My point is that the seq library doesn't do KEY, it only does TESTFN,
presumably because the person who wrote it was inspired by functional
languages.

We have virtually all the same functions in cl-lib.el, and the
inspiration there is from Common Lisp, so all those functions take KEY
(and a dozen other keyword parameters).

Myself, I'd prefer that virtually all the functions in seq.el take a
KEY, too, but that's not what that library is.  Adding KEY to just
`seq-uniq' doesn't make sense from a library design standpoint.