GNU bug report logs - #57079
29.0.50; Performance of seq-uniq is not very good

Previous Next

Full log

View this message in rfc822 format

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 57079 <at> debbugs.gnu.org, stefan <at> marxist.se, Juri Linkov <juri <at> linkov.net>
Subject: bug#57079: 29.0.50; Performance of seq-uniq is not very good
Date: Mon, 15 Aug 2022 08:39:51 +0200

Michael Heerdegen <michael_heerdegen <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.