From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Madhu Newsgroups: gmane.emacs.devel Subject: PCL [Re: What's missing in ELisp that makes people want to use cl-lib? Date: Mon, 20 Nov 2023 20:00:40 +0530 (IST) Message-ID: <20231120.200040.1734438601830491358.enometh@meer.net> 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=us-ascii Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="27119"; mail-complaints-to="usenet@ciao.gmane.io" To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Nov 20 15:31: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 1r55Je-0006uA-TF for ged-emacs-devel@m.gmane-mx.org; Mon, 20 Nov 2023 15:31:58 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r55Iy-00079J-Kc; Mon, 20 Nov 2023 09:31:16 -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 1r55Iw-00078v-Be for emacs-devel@gnu.org; Mon, 20 Nov 2023 09:31:14 -0500 Original-Received: from smtp0.ctinetworks.com ([205.166.61.207]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1r55Iu-000216-F9 for emacs-devel@gnu.org; Mon, 20 Nov 2023 09:31:14 -0500 Original-Received: from localhost (unknown [117.254.36.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: enometh@meer.net) by smtp0.ctinetworks.com (Postfix) with ESMTPSA id 28552306F088 for ; Mon, 20 Nov 2023 09:31:02 -0500 (EST) X-Mailer: Mew version 6.9 on Emacs 30.0.50 X-ctinetworks-Information: Please contact the ISP for more information X-ctinetworks-MailScanner-ID: 28552306F088.AF1D5 X-ctinetworks-VirusCheck: Found to be clean X-ctinetworks-Watermark: 1701354668.47154@mRRsZoMEA5kZGoKXm2xhMA Received-SPF: pass client-ip=205.166.61.207; envelope-from=enometh@meer.net; helo=smtp0.ctinetworks.com X-Spam_score_int: -3 X-Spam_score: -0.4 X-Spam_bar: / X-Spam_report: (-0.4 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_SORBS_WEB=1.5, SPF_HELO_PASS=-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:313047 Archived-At: * Gerd M?llmann : Wrote on Thu, 16 Nov 2023 21:09:50 +0100: > 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. There are advantages in the complexity of PCL. For instance, AFAIK there is no way to undefine a method defined with cl-defmethod after defining it without restartimg emacs, which I think misses the fundamental point about Lisp. I remember making made a few posts in 2016 on comp.lang.lisp about the design and use of I faced with cl-generics, where I pointed the issues I hit.