From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: "Alfred M. Szmidt" Newsgroups: gmane.emacs.devel Subject: Re: cond* vs pcase Date: Wed, 07 Feb 2024 14:12:50 -0500 Message-ID: References: <87il32iwmm.fsf@posteo.net> <87o7cttu4l.fsf@posteo.net> <87o7cts9nc.fsf@posteo.net> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="30475"; mail-complaints-to="usenet@ciao.gmane.io" Cc: yuri.v.khan@gmail.com, philipk@posteo.net, emacs-devel@gnu.org To: Arthur Miller Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Feb 07 20:13:41 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 1rXnMZ-0007gk-PK for ged-emacs-devel@m.gmane-mx.org; Wed, 07 Feb 2024 20:13:39 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rXnLr-0001qy-B9; Wed, 07 Feb 2024 14:12:55 -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 1rXnLp-0001qV-9U for emacs-devel@gnu.org; Wed, 07 Feb 2024 14:12:53 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rXnLn-0001Hh-5Y; Wed, 07 Feb 2024 14:12:51 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=Date:References:Subject:In-Reply-To:To:From: mime-version; bh=3V5BdH5FNY++Bt9zNBwvxS2HFLBMjEZrH5boevdExso=; b=KM8dLwswtqyL 5Y5+ich5ehyVagW5IvovsupUpMzxiHnN4AKn9ZM6XQ9y/CJUpUODmdAAKSCEpjUzcowCUfRQcnfH/ 0vrvYVFwxOPDKBLjlf5jriafz+F1Ptbhcqq02SP/7MBZnqnXUWEqwft5Q81FIXBZik06oQ/mGK8kl L3Y84oDlp44MQ4pfdzyKPEG1mhU5KbqwPLee6bSV16hVbRdWCfh6SazA0rKOXzj/CozHP8d5Yq3xS pl33OeP2/FIba7XQGu+uAlVieCSEsTm3Pcm5RLJbQnLXl4/lnkpVFqt1oldUnxcfz1Y82wo97gnSw qZv3gdABFrHWnpmmc+6emQ==; Original-Received: from ams by fencepost.gnu.org with local (Exim 4.90_1) (envelope-from ) id 1rXnLm-0006Z9-4h; Wed, 07 Feb 2024 14:12:50 -0500 In-Reply-To: (message from Arthur Miller on Wed, 07 Feb 2024 19:36:56 +0100) 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:315989 Archived-At: > I am not sure if Alfred meant that in his first message, perhaps he did, but > Drew seems to be more in line with that thinking. At least I understand him so. > > I'm not alluding to any specific design principle, the core issue at > hand is communicating with the person reading the code. Yes, that is how I understand you; but I'll answer same as to Drew; I don't agree that this is the best way of expressing the intention. Both pcase and cl-case in this particular simple context I have posted, express the intention equally well. [...] We disagree to the point that there cannot be any agreement on the topic, they do not express the same intent, just like a cond and explicit (eql .. 'foo) do not express the same intent as using 'case'; they maybe do the same thing, but there is more about intent than that. As for tangents of optimizations, I'm not going to discuss them at all. It is rather that you are aware of the details of cl-case and pcase and understand that the pcase is more powerful and can express more powerful constructs. However just that fact that it is more powerful, does not mandate use of "simpler" construct. As Adam illustrated, in this particular scenario, cond, cl-case and pcase expressed equally well the intention. The runtime cost is about the same too; so I don't think the implementation deatails should guide the decision. That seems to me like some sort of premature optimization, peep-hole optimization of intentions. I am not sure how to express myself here :). > The reason why we have ASSOC, ASSQ, ... are because they make it I am not sure if the reason is the clarity. I think we have, with all right, gone away from abbrevs and accronys such as "assq" or "memql" in function and variable names to more self-documenting code. Those functions are historical artefacts in my eyes. These functions are integral parts of Lisp, to call them "historical artefacts" is to not understand or care to understand the language. > _clear_, _easy_ to understand code and to _use_. A generic version is > not as easy to understand, or use. Which is also a reason why > keywords are generally eskewed in Emacs Lisp. Is this not clear and understandable: (member elt list #'eql) (memeber elt list :test 'eql) You missed a crucial part: to use. Writing code is also important. But no, I do not find those clear at all, you have more symbols to read, specially when comparing against common types like integers, or symbols. You have the question of _why_ did the writer use that exact form instead of already, well known, well documented, functions like memql. So under no cirucmstance does the above mean clear or understandable, rather it raises more questions. Can we be more explicit in communication the intention which test funciton to use, if communicating exactly that intention is really important. Approoos nameing and historical artefacts, I read once an interview with Ken Thompson; I don't remember on which site, so I don't have the link, but they were asking him a bit about Unix design and a bit about C language amongst other things. On the question if he regret anything abotu Unix design, he said, if he regret he used "creat" instead of "create" as the name for the syscall. I fail to see the point? Would you prefer mem-eql / member-eqal over memql? They would do the same thing, which isn't the case comparing pcase to case, cond to cond*, ...