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

Previous Next

Full log

Message #70 received at 57079 <at> debbugs.gnu.org (full text, mbox):

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: Re: bug#57079: 29.0.50; Performance of seq-uniq is not very good
Date: Wed, 17 Aug 2022 13:01:20 +0200

Michael Heerdegen <michael_heerdegen <at> web.de> writes:

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

Well, history tells a different tale.

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

We've dropped that argument a long time ago -- it's free-for-all-time in
cl-lib.el. 

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

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.

Previous Next

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