From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Michael Heerdegen Newsgroups: gmane.emacs.bugs Subject: bug#57079: 29.0.50; Performance of seq-uniq is not very good Date: Tue, 16 Aug 2022 01:37:50 +0200 Message-ID: <87pmh1axip.fsf@web.de> References: <83tu6ltlcq.fsf@gnu.org> <87y1vxwe0y.fsf@gnus.org> <83k07htjxf.fsf@gnu.org> <87o7wtwcu9.fsf@gnus.org> <83fsi5tj31.fsf@gnu.org> <87k07hwbgs.fsf@gnus.org> <838rnxti1k.fsf@gnu.org> <878rnxwayl.fsf@gnus.org> <837d3hth7r.fsf@gnu.org> <86mtcdnrad.fsf@mail.linkov.net> <878rntr49y.fsf@gnus.org> <87lertnhdc.fsf@web.de> <87pmh4jraj.fsf@gnus.org> <87wnbboprt.fsf@web.de> <87tu6ec8nc.fsf@gnus.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="29411"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) Cc: Eli Zaretskii , 57079@debbugs.gnu.org, stefan@marxist.se, Juri Linkov To: Lars Ingebrigtsen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Aug 16 01:39:26 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oNjg5-0007Ot-59 for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 16 Aug 2022 01:39:25 +0200 Original-Received: from localhost ([::1]:52548 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oNjg4-0002NF-95 for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 15 Aug 2022 19:39:24 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:58210) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oNjfj-0002Ld-4G for bug-gnu-emacs@gnu.org; Mon, 15 Aug 2022 19:39:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:54583) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oNjfi-0005AF-N9 for bug-gnu-emacs@gnu.org; Mon, 15 Aug 2022 19:39:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oNjfi-0002Zq-Cu for bug-gnu-emacs@gnu.org; Mon, 15 Aug 2022 19:39:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Michael Heerdegen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 15 Aug 2022 23:39:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 57079 X-GNU-PR-Package: emacs Original-Received: via spool by 57079-submit@debbugs.gnu.org id=B57079.16606066839840 (code B ref 57079); Mon, 15 Aug 2022 23:39:02 +0000 Original-Received: (at 57079) by debbugs.gnu.org; 15 Aug 2022 23:38:03 +0000 Original-Received: from localhost ([127.0.0.1]:44332 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oNjek-0002Yc-ST for submit@debbugs.gnu.org; Mon, 15 Aug 2022 19:38:03 -0400 Original-Received: from mout.web.de ([212.227.15.3]:38885) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oNjeh-0002Y6-61 for 57079@debbugs.gnu.org; Mon, 15 Aug 2022 19:38:01 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=web.de; s=dbaedf251592; t=1660606672; bh=SNdY45d3i/CWKaZ3VPLTblVvk9zW5UKPL4uKMvVnn58=; h=X-UI-Sender-Class:From:To:Cc:Subject:In-Reply-To:References:Date; b=iP6HtDmPYfXSmwpq2LYe+XsL/ern7amVK7CVdTqyp+zzdjWp27weBj6ShpnErW7Xd rZHWUpQyFNJ8B1Qa846AxRvVVMQVmAM1J7hOFokp0EaAsiEMhUM4Zwk/gsDFf1EcYX jKeCZD+0joPflXD61gK20B+JpB9WEXbeEtLsOq30= X-UI-Sender-Class: c548c8c5-30a9-4db5-a2e7-cb6cb037b8f9 Original-Received: from drachen.dragon ([84.57.248.18]) by smtp.web.de (mrweb006 [213.165.67.108]) with ESMTPSA (Nemesis) id 1McZjd-1nnZUb0EYP-00cXrX; Tue, 16 Aug 2022 01:37:52 +0200 In-Reply-To: <87tu6ec8nc.fsf@gnus.org> (Lars Ingebrigtsen's message of "Mon, 15 Aug 2022 08:39:51 +0200") X-Provags-ID: V03:K1:5xMXndBZhZ4G3BiMu2oj627ehU8w4VarY2sQdnds/3kUfLjYeEo M8MtKI2z3tTfmbu2ZJ15MQhzsWs6l+MIjel8rtgx2G3m/MW5eyt2LbPeQetn/1Z9TV15Sgg uWdRqi2IC5YCDn2xolCR4cyB+VCE49/RQPLrfc2KBKkL71ShiU2X9ZNA7lvmO+ElXq6pocL E5VXgUFiy05ZOEMwlFFfQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:uPg+RhbUmYQ=:Ia/1Q/maTa+271VaG275B+ +OfZuNb8iLKW9A71oEeAoZ0PjgsFUluZMHDTUFx+uGT5HWZllOQqihUCoIwFXbZjkOLd5gBrp lX9RIHBbmTrGQJc/TB0MOn/tt06jRE02Ct//7h7uYnVEiYeR1Ntf6WlZFRSUesneiXxs4Wk6u uQy/7wNjEBx9VtoBBTt181U70YdmCp4hzOAba7kWLTFRePP5xA829U3e4FkyF9ss7YE4RnqGv 8y/368rFHV4rJR+EWu7HaJBuP/0PPQ4kiu/lK55JjxQ8fFQqzCBVDGRxN9V18oAiHMUYzzk4D kqaPP0LCEa0gzIU/on9z6bDdHcXAUNifpHjDWBjg2qb/hTHWcsTu8GRqzF4NpEjkCeXxAErUv ugIDQW7R1NGqLCOivfIde9TWVL/EUBbzUPwuJNIlRTSFjVggyH/WELny1CO3QbKyM8Ap3yZJg PuXNkj0Hzce8GkusGMp4aMyFO3vwPMZEYpK9JCI3Sz7hp/QVsBh+8iCoIDRpSETyzSK/Kl0+F j/Jxl5KJZKY7bdsLn8kS5JcyboZVE22LMaaMzJeKHAftszXBIGfyrSZy/RU8BuJoToz1CI8Gl hx0CDnNqsaSkTd/sON6VWDrx9Ao1HpHmxBFJzGWv+qjBwErr+HwDM5jWlzpp1OjoBfTw+2CMI 7Km4WsB6GxpH64FfDATMC+BgCKARtuXwxozXJ3Nzyi+ndpgY100qPvrXXhDEl+7fWXQM+SAEz 18J6x3LD3lxtfyF3QLO8WO4HOPhzGiL1FgFY8UkxuDwuZKRG25adMs+r/LW0KFM0YfSfvueK X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:239855 Archived-At: Lars Ingebrigtsen 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.