From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Barry Fishman Newsgroups: gmane.emacs.devel Subject: Re: cond* vs pcase Date: Wed, 07 Feb 2024 10:03:44 -0500 Message-ID: <7ny1bw71v3.fsf@ecube.ecubist.org> References: <87il32iwmm.fsf@posteo.net> <87o7cttu4l.fsf@posteo.net> <87ttml8oty.fsf@posteo.net> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="39089"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) To: emacs-devel@gnu.org Cancel-Lock: sha1:9b+cWKvzOFMotPJ32S7YlgrPCOU= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Feb 07 16:04:30 2024 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 1rXjTS-0009x3-BX for ged-emacs-devel@m.gmane-mx.org; Wed, 07 Feb 2024 16:04:30 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rXjSx-0007FL-P1; Wed, 07 Feb 2024 10:03:59 -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 1rXjSu-0007Ew-Mi for emacs-devel@gnu.org; Wed, 07 Feb 2024 10:03:57 -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 1rXjSt-0004PT-75 for emacs-devel@gnu.org; Wed, 07 Feb 2024 10:03:56 -0500 Original-Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1rXjSp-00093V-Vf for emacs-devel@gnu.org; Wed, 07 Feb 2024 16:03:51 +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: -16 X-Spam_score: -1.7 X-Spam_bar: - X-Spam_report: (-1.7 / 5.0 requ) BAYES_00=-1.9, 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:315980 Archived-At: On 2024-02-06 17:50:01 GMT, Thierry Volpiatto wrote: > Philip Kaludercic writes: >> "Alfred M. Szmidt" writes: >>> "Alfred M. Szmidt" writes: >>> Being able to do equal instead of eql is also something that speaks in >>> favour of pcase... >>> >>> It speaks more in favor of having CASE where you can change the >>> comparison operator or a CASE-STRING or similar, not something much >>> more generic pcase (or even cond*!) -- i.e. why use pcase/cond* when >>> you're not using any of the features that are the main point of those >>> two macros. >> >> I am sorry, but I don't follow your point here either. Is the general >> claim, that one should only use whatever exactly and at most satisfies >> the needs at hand? > > Also interning strings just for the purpose of comparing them with eq or > eql is questionable... If I remember right, in Common Lisp long case statements could be optimized by the compiler to do a hash lookup in a table generated at compile time. The case form made it easy for the macro/compiler to figure this out, and compilers were not as good as they are now. Incidentally in Haskell, case is quite a different operation. There the types are declared and know by the compiler, so it more a matter of deconstructing a well defined type and possibly then checking the values to meet some requirement. This is far simpler for Haskell programmers to recognize than the more complex situation that pcase/cond* are trying to solve. What bothers me the most about it is that rather the breaking these problems into simpler operations and providing a means of composing them to handle more complex situation, the pcase/cond*/loop constructs mix them all in to a single form. This is defended by saying that it helps move some of the complexity from the user to the macro processor. But like the current generation of 'generative AI' solutions to problems, it seems to hide the complexity in a way that subtle errors get hard to discover. New coders end up spending their time copying code fragments rather than understanding what is going on. -- Barry Fishman