From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: What's missing in ELisp that makes people want to use cl-lib? Date: Thu, 16 Nov 2023 23:54:01 +0200 Message-ID: <56accb10-2a3c-7670-1687-4ae1d7e374e8@gutov.dev> References: <9ab5d2bd-a648-cae0-a4a7-ae86be10af0f@gutov.dev> <87r0kuqxbf.fsf@gmail.com> <54e115a2-fc36-3056-a030-0dbf32416ddb@gutov.dev> <43f290b0-4119-597b-c89a-0fb4c7db1665@gutov.dev> <1e7fe1ef-af7d-3222-7b9e-b569b3c97ccf@gutov.dev> <22e4cb4d-a8f3-1530-881d-b8c59c5d969b@gutov.dev> <339b58d6-5a44-8393-c2cd-4c935147dde3@gutov.dev> <877cmhrcsf.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="2504"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Cc: Eli Zaretskii , michael_heerdegen@web.de, emacs-devel@gnu.org To: =?UTF-8?Q?Gerd_M=c3=b6llmann?= , =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= , Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Nov 16 22:55:01 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 1r3kKC-0000In-Nb for ged-emacs-devel@m.gmane-mx.org; Thu, 16 Nov 2023 22:55:01 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r3kJQ-0007Kf-HN; Thu, 16 Nov 2023 16:54:12 -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 1r3kJO-0007KX-KD for emacs-devel@gnu.org; Thu, 16 Nov 2023 16:54:10 -0500 Original-Received: from out2-smtp.messagingengine.com ([66.111.4.26]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1r3kJL-0003Yx-GZ; Thu, 16 Nov 2023 16:54:09 -0500 Original-Received: from compute6.internal (compute6.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id C554F5C01BA; Thu, 16 Nov 2023 16:54:05 -0500 (EST) Original-Received: from mailfrontend1 ([10.202.2.162]) by compute6.internal (MEProxy); Thu, 16 Nov 2023 16:54:05 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm2; t= 1700171645; x=1700258045; bh=cYgOVC05nToQfCOtLux+JwW7lI9PDuLAS+8 Ba6p1G1Y=; b=JCOHyjHklcYFGhKFlnZn3ajFQ6BaxfR8Ghp0Da59KzeGONK+bd3 3lAbLHkXpzEjKwBCob4TsQPDoXJdeSTFmQwLKq1Ei0JdoyGHGtD7pj21D2md/l2X U5G/Gs3kOoq1UqycRyl2A0/C0IcdWkKZy69JCgCXpye8C6yZAvfWxKCav23cIRDq OkhGt82KcU8obAiC3llQTtkeft7/i7Bfo6thRV7v2QRjxc3MOCGS/lgaImHw74Da QvsHK+t6FGZqDjGEQ9WkwflhSEX047v7ViqU0Kbd3oiJYyHHTCCvVHRtdiH7ryvV vSdAceaa2kS15Y21gddUHnA1gOhUCDPBluw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t= 1700171645; x=1700258045; bh=cYgOVC05nToQfCOtLux+JwW7lI9PDuLAS+8 Ba6p1G1Y=; b=gnbfGqKWCNyhlkgk+B3DOFnQXcXlRbhPwkQ+wbOMuu1nVQyQ7cv xgjhheu6ClPS6A3ad5UPZ1QQWGcR14gV488HhYm0egw/4RPv38T5C851+MbNCg8M T2LwYW2y2voxtClaoFh2qTQr3jTaRpHTeNFf1LQm7uwcNJN8FQ4buIFXoHAbC9uC 2EqWVbJMg6ye2DiTw5UNqe7mMlZeh/+1txORQKu1e+yOm0Kw2jr43ijJjcbBcqG5 the9j+csiI7LGbLWBENaxYrrsi8NGvPTcDpzBv9ROUtjsZzbc5422hRS9/CbMaeO +j140dDpy6Hcau8NgopUXSkbUejdW6+5nMA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrudefkedgudehfecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefkffggfgfuvfevfhfhjggtgfesthekredttdefjeenucfhrhhomhepffhm ihhtrhihucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvghvqeenucggtffrrg htthgvrhhnpefhffehleejffegffeugefhkeektdffgfehjedvgeejtedtudehueffgffg feejheenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe gumhhithhrhiesghhuthhovhdruggvvh X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 16 Nov 2023 16:54:03 -0500 (EST) Content-Language: en-US In-Reply-To: Received-SPF: pass client-ip=66.111.4.26; envelope-from=dmitry@gutov.dev; helo=out2-smtp.messagingengine.com X-Spam_score_int: -49 X-Spam_score: -5.0 X-Spam_bar: ----- X-Spam_report: (-5.0 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-2.193, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham 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:312839 Archived-At: Thanks, Gerd. I think Stefan is not subscribed to this list anymore, so I'll Cc him in case he has something to add (or considers worth improving). But cl-defmethod with just one method resulting in a simple function definition in an experimental fact (evaluate (cl-defmethod abc () 345); then (cl-defmethod abc () 345) returns (lambda nil (progn 345))), so that must be faster, without any computation of applicable methods. The comment above the code you quoted mentions "generic functions with a single method"; maybe it was written before the above optimization was made. On 16/11/2023 22:09, Gerd Möllmann wrote: > Gerd Möllmann writes: > >> João Távora writes: >> >>> AFTER loading it >>> >>> ... >> The magnitude of the difference when additional methods are defined I >> find surprising. I take it as a strong indicator that cl-generic.el >> indeed works completely differently than PCL. Assuming it is not a bug >> af some sort. That the manual nowhere uses the term "discriminating >> function" might also be a hint. > Looking a bit at cl-generics.el, at least the discriminating functions > part is indeed like nothing in PCL. And discriminating functions are not > in the manual, because there are none. > > Disclaimer: I do not know cl-generics.el, and I've just looked enough to > get an impression. > > So: I would describe the difference between PCL and cl-generic something > like static vs. dynamic, perhaps. > > PCL goes to great lengths computing applicable methods etc. constructing > an as optimal as possible discriminating function. Once this has all > been done, nothing more has to be done at runtime. When methods are > changed, added etc. the whole thing is done from scratch again. > > Cl-generics, in contrast, I'd say relies on runtime computation of > applicable methods and so on, plus memoization. If someone wants to see > what a generic function looks like, see cl-generic-define -> > cl--generic-make-function -> cl--generic-make-next-function -> > cl--generic-get-dispatcher. There we see > > (funcall > cl--generic-compiler > `(lambda (generic dispatches-left methods) > (let ((method-cache (make-hash-table :test #'eql))) > (lambda (,@fixedargs &rest args) > (let ,bindings > (apply (with-memoization > (gethash ,tag-exp method-cache) > (cl--generic-cache-miss > generic ',dispatch-arg dispatches-left methods > ,(if (cdr typescodes) > `(append ,@typescodes) (car typescodes)))) > ,@fixedargs args))))))))) > > The hash-table is a cache, the inner lambda is the function definition > of the gf, the apply is the execution of an effective method, AFAIU. If > we hit an argument combination not in the cache, we compute applicable > methods at runtime, I believe. > > A bit strange is that cl--generic-next-function seems to be called > recursively in the process, which I think could create another such > hash-table. Or I'm reading that simply wrong, as I mentioned I just > wanted to see if cl-generic is so different, so I didn't spend much time > on this. > > The question how that leads to such-and-such performance effects I can't > answer. I haven't seen such an implementation before. > > And I'm not saying it's bad! There are very very very (did I say very > enough?) good reasons to try and avoid the incredible complexity of > something like PCL.