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: Sat, 20 Aug 2022 05:17:26 +0200 Message-ID: <871qtby56h.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> <87pmh1axip.fsf@web.de> <87fshvjfr3.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="17767"; 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 Sat Aug 20 05:18:16 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 1oPF03-0004LQ-Ct for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 20 Aug 2022 05:18:15 +0200 Original-Received: from localhost ([::1]:57370 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oPF01-0005Ma-LG for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 19 Aug 2022 23:18:13 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:40990) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oPEzs-0005MQ-4l for bug-gnu-emacs@gnu.org; Fri, 19 Aug 2022 23:18:04 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:41471) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oPEzq-0004VL-Qq for bug-gnu-emacs@gnu.org; Fri, 19 Aug 2022 23:18:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oPEzq-0006ot-8N for bug-gnu-emacs@gnu.org; Fri, 19 Aug 2022 23:18: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: Sat, 20 Aug 2022 03:18: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.166096545826183 (code B ref 57079); Sat, 20 Aug 2022 03:18:02 +0000 Original-Received: (at 57079) by debbugs.gnu.org; 20 Aug 2022 03:17:38 +0000 Original-Received: from localhost ([127.0.0.1]:59453 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oPEzS-0006oF-IA for submit@debbugs.gnu.org; Fri, 19 Aug 2022 23:17:38 -0400 Original-Received: from mout.web.de ([212.227.15.3]:36725) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oPEzP-0006o0-Nh for 57079@debbugs.gnu.org; Fri, 19 Aug 2022 23:17:37 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=web.de; s=dbaedf251592; t=1660965448; bh=cwnVgnv1YpKLWfb1yaJGbycWrGCb53tZC1Wj3AIuapo=; h=X-UI-Sender-Class:From:To:Cc:Subject:In-Reply-To:References:Date; b=Io44/dUIl2G4VaUDAc4uPUpQI95xHuoj9rCy8j0tCoU04otk3WYyIGv9sU4SM/mkM VAj1QJcvaYdeVCyets5Sq7f26lm2gKoZGugUk0AW5OheZQMR9iwHLTjmjwhyS3wtV6 tY5kQYRcV7SuPuN+kVFqy65C/ZXd0oSZt+fNnPqc= X-UI-Sender-Class: c548c8c5-30a9-4db5-a2e7-cb6cb037b8f9 Original-Received: from drachen.dragon ([84.57.248.18]) by smtp.web.de (mrweb005 [213.165.67.108]) with ESMTPSA (Nemesis) id 1MNwfU-1onMTw0ytM-00OXIr; Sat, 20 Aug 2022 05:17:28 +0200 In-Reply-To: <87fshvjfr3.fsf@gnus.org> (Lars Ingebrigtsen's message of "Wed, 17 Aug 2022 13:01:20 +0200") X-Provags-ID: V03:K1:ppZ83VxrpuuYjGtLE0jBy3/Dw8FlCVZt0h+akvpOY7pr6+kPXff wnOGHOUamsVwiRvogoH3HyA4GL69GDVm1I41bVbFDynCJn6h8PKw/W2DrofO+dgUjxAqGqG ixik59xxMVKTCNOmLJJ6iBMkFFZ+iJ1NLleu3RW3D/yRRVOCDXsP0mTwSKKuijkXU4O/ymK V9xxxv38MIo6B+LHXlEbA== X-UI-Out-Filterresults: notjunk:1;V03:K0:Gfd0JbeGRjc=:MEVGNL/8Snj0hzj/DhzSeo IKk8SA6ekcV/87ukIoUfdNNcuSRn/w4Z4rqk80aftxF2jzMpj6dIQODRZBPcMTOP67st24Tu8 YzGNM1pcIe4M0SvKKbbqJCcmOijjsgXloMGFNi58wv+Apb72Wkq+h7jvCa1/BvdYYjah8R65k ttC9TUpIQ8Evg2GyEvaYKvg4leN9VMiGXHbgekOaISQSxW/y41vJtTFiDG6TSbi0ReQDavraW zLVERI67eVErKxetb2kcDh1JuliJKbq4k8G32jwaJKGI35epafgUzfY/tKGhu6QmDUyROxL9v I5bvJvcTgyz/UC+A4MY3lE2SI3EWL+w7kpJguy7S45jpBHEPRBej+H+KZYql6Vn9obEmGSNYk 7aqbDWCxDioB4dKbnbdD9X3VxuSBEPVyaYRe3J9WRLOE+nHeRRTjroz2MHYem4bTJVnbGtvfI nOnDIc+1RZcS3fLfSXWClHB39H85RSv+tARe7o/HZA50q4DMaw2zo2QkhjpFrkAlx29e+IcTC ToHsBSJE6ec+7M7V6fXUj/guPVSExjEf7XshU1jY1n8buKxEnIR1fcF1obai2474q3bTtIE/n 6nqLoJkt/H5V+qmyFqFtZXioxfN7Vj6ATj9bjE4KnlpXmJE/XMUB/Cn5pPfaI4Rqpvu5nUpd8 jdpfEkkj3n2C+cLaZ0qOvnwCQz3c68pXuVBNws2qfWYq9CtS2ROkvKEvsTauO0Ik49nM7O1MU 4pI0h9+QqaZQz4AtaQwN5Rj3Id2xM+CknxEVqswHyZldPWrzxr9MoMuGJsuFclumyEWQlxcQ 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:240227 Archived-At: Lars Ingebrigtsen writes: > > [...] 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. Are we going to merge (or cherry pick) stuff from seq.el to cl-lib? Probably not, so let's disregard the idea that cl-lib will ever be a complete replacement for seq.el stuff. > 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. I don't think I get it/buy it. Could you explain (in theory, a yes/no question) why we should not support that use case in `seq-uniq' without saying the word "CL", and if you say "design", without comparing with the design of CL? If you can't: seq.el has lots of overlaps with other parts of Emacs. What is so special about CL that an overlap is not acceptable? Or what is special about this task that it is not possible to handle it in several places? Please remember: I don't think in the term of "key functions", and I don't want to introduce something like that to other seq.el functions, so here is no argument. I'll stop asking after this Email because we are going in circles - but so far I just don't find your argumentation conclusive. Actually, this `seq-uniq' function is a logical part of the yet-to-write set.el library. The task/semantics is: Find a subset containing exactly one representative from each class of the elements of a given set. But I guess this library would also not be allowed to solve this task? Why do we add and develop them then at all? Wouldn't it be better to improve and develop cl-lib further instead then? Serious question. TIA, Michael.