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.devel Subject: Re: What's missing in ELisp that makes people want to use cl-lib? Date: Tue, 14 Nov 2023 15:43:43 +0100 Message-ID: <874jhotmxs.fsf@web.de> References: <87il6bt4z0.fsf@yahoo.com> <8734xetjkk.fsf@yahoo.com> <87cywhsrcf.fsf@yahoo.com> <87cywgx1z0.fsf@web.de> <83wmuowwp3.fsf@gnu.org> <8334xcwank.fsf@gnu.org> <320999cc-6c83-2315-0044-cc0403400af3@gutov.dev> <87ttpqjbka.fsf@web.de> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="15609"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) To: emacs-devel@gnu.org Cancel-Lock: sha1:IN8/we2yxRHSKsU0s94zOB4cT2A= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Nov 14 15:46:59 2023 Return-path: Envelope-to: ged-emacs-devel@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 1r2ugs-0003we-Tu for ged-emacs-devel@m.gmane-mx.org; Tue, 14 Nov 2023 15:46:58 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r2udj-0006K5-PM; Tue, 14 Nov 2023 09:43:43 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1r2udh-0006Je-Ow for emacs-devel@gnu.org; Tue, 14 Nov 2023 09:43:41 -0500 Original-Received: from ciao.gmane.io ([116.202.254.214]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1r2udf-0000Ge-PJ for emacs-devel@gnu.org; Tue, 14 Nov 2023 09:43:41 -0500 Original-Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1r2udc-0009nc-As for emacs-devel@gnu.org; Tue, 14 Nov 2023 15:43:36 +0100 X-Injected-Via-Gmane: http://gmane.org/ Received-SPF: pass client-ip=116.202.254.214; envelope-from=ged-emacs-devel@m.gmane-mx.org; helo=ciao.gmane.io X-Spam_score_int: -13 X-Spam_score: -1.4 X-Spam_bar: - X-Spam_report: (-1.4 / 5.0 requ) BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:312734 Archived-At: João Távora writes: > Now really, sure? What about those generic functions that you > presumably have to shortcut? Won't it break an existing contract to > users that all of the sudden you're not calling them anymore for > certain types of sequence? If you don't make a mess, no. It's of course possible to choose different implementations (algorithms) for different types of sequences. There a few technical reasons why seq.el should be slower. > And how are you going to do this without introducing non-destructive > versions of the seq.el utils? That's a thing we probably can't do, yes. But this shouldn't lead to algorithms reaching a different complexity class, or running slower by a factor N with large N. Do we have places in the Emacs Elisp sources where this would make a significant difference? > And wasn't it a goal here to end up with a smaller dictionary of such > utils? Won't it bloat up comparibly to cl-lib while still being less > versatile? The result will still be much smaller than cl-lib. The idea is of course not to use nonsense algorithms just to spare some dozens of Bytes. > > These kinds of benchmarks are more or less irrelevant. > > I beg to differ, I think a recommended sequence processing > function that needlessly conses and takes orders of magnitude more > time to do its job is really quite relevant. Elisp is still a > "LISt Processing" language by and large. > > But also, I have to ask: what _would_ be a relevant benchmark > to you? You misunderstood. Of course do these benchmarks matter very much, but as I said, please, this thread is not a seq.el bug report. What I said is that benchmarks do not much tell us about how our future treatment of cl-lib should look like as long as seq.el can be improved and sped up and you argument with seq.el efficiency. > Just for cl-set-{n}difference, I'm seeing significant usage in core > right now, direct _and_ indirect. I'm not sure all the authors, let > alone users, of these packages would like to learn that these parts of > their code have suddenly become a full order of magnitude slower, let > alone users using such things, by virtue of some cl-lib.el -> seq.el > operation as is being suggested here. These actually do not really fit in seq.el but would rather be a natural part of set.el. > No, the point is that it hasn't. Some of the destructive versions > weren't even destructive at all! if you take a look at my code you'll > notice I optimized cl-lib considerably in very few cases. > There's a lot more that can be optimized there. Other parts were optimized in the time, of course. > The seq.el file has "optimized implementation for lists section" by > tweaking the generics for lists. I find plausible the designer of > seq.el noticed that it is still much slower to do this but wanted to > keep a specific generic function contract anyway. Again, such a contract does _not_ per se have implications about efficiency. A seq.el implementation of a generic function for lists can find the type is 'list' and then use exactly the same algorithm as cl-lib. All you have to do additionally is one check (`listp'). This is currently not the case everywhere in seq.el, some algorithms perform repeated, strictly speaking redundant, tests, but that can (and should be, where it matters) avoided. > Finally, please note I'm not trying to bash seq.el. I think it > has its place -- polymorphic sequences are great, if I ever > need them -- , but its use should _also_ be discriminate, not > indiscriminate. Same for your set.el idea: IMHO it's very welcome, > but I think it will suffer (and gain, of course) from the same > kind of tradeoffs as seq.el. The only relevant question for me in this message is: is an improved seq.el good enough to replace the sequence functions in cl-lib? I think it is. To convince Eli that it is not, he would need something like a real-life case where the seq.el functions make some program significantly slower, and where we know that this can't be improved in seq.el (something like sorting a million three-element lists in a row is not a good example). Michael.