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: Michael Heerdegen <michael_heerdegen <at> web.de>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
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: Tue, 16 Aug 2022 01:37:50 +0200

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> 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.

But it makes sense from the viewpoint of practical requirements.  Half
of all use cases will run much slower if we don't support this case.
Practical requirements and efficiency are more important than a slippery
as an eel design.

I come from mathematics, I looked at the code usages and saw equivalence
classes and projection functions hiding behind.  I regret that I ever
used the work "key function".

It would be a bad design choice not to address all the situations where
abstraction wrt equivalence classes makes sense and improves a library
just because CL also does that.

Or do you have an idea for a different design that addresses such cases?
Simply ignoring them makes no sense.

And I see a bigger (design) problem here: as you said, there is a large
overlap between seq.el and cl-lib.el.  Once we said we don't want to
extend CL too much because it should be compatible with Common Lisp.
That was one reason why seq.el had been started.  When we now say that
we can't implement something in seq.el, something that is a practical
need, because it already exists in cl-lib, we have a problem: we will end
with two incomplete and half baked solutions for sequence handling.

People will then have to use both libraries to get efficient code and
support for their use cases, merging functions from libraries in their
code.  This should not be our long-term objective.  It would also be a
very bad design, in the end, for Emacs.

Michael.

Previous Next

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