From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: combining cond and let, to replace pcase. Date: Sun, 19 Nov 2023 21:36:31 +0000 Message-ID: References: <878r6u3s7f.fsf@web.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="40444"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Richard Stallman , Spencer Baugh , emacs-devel@gnu.org To: Michael Heerdegen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Nov 19 22:37:49 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 1r4pUD-000AJE-Cc for ged-emacs-devel@m.gmane-mx.org; Sun, 19 Nov 2023 22:37:49 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r4pTJ-0001K3-6Q; Sun, 19 Nov 2023 16:36:53 -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 1r4pTG-0001Jj-W1 for emacs-devel@gnu.org; Sun, 19 Nov 2023 16:36:51 -0500 Original-Received: from mail.muc.de ([193.149.48.3]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1r4pTE-0004Ug-T4 for emacs-devel@gnu.org; Sun, 19 Nov 2023 16:36:50 -0500 Original-Received: (qmail 32684 invoked by uid 3782); 19 Nov 2023 22:36:37 +0100 Original-Received: from acm.muc.de (p4fe15449.dip0.t-ipconnect.de [79.225.84.73]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Sun, 19 Nov 2023 22:36:36 +0100 Original-Received: (qmail 12477 invoked by uid 1000); 19 Nov 2023 21:36:31 -0000 Content-Disposition: inline In-Reply-To: <878r6u3s7f.fsf@web.de> X-Submission-Agent: TMDA/1.3.x (Ph3nix) X-Primary-Address: acm@muc.de Received-SPF: pass client-ip=193.149.48.3; envelope-from=acm@muc.de; helo=mail.muc.de X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, 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:313021 Archived-At: Hello, Michael. On Sun, Nov 19, 2023 at 12:20:20 +0100, Michael Heerdegen wrote: > Richard Stallman writes: > > Some of them could do destructuring as well as matching. > > I hoipe that using a few constructs to divide up the job will avoid > > the kludginess of pcase's bells-and-whistles-for-everything approach, > > resulting in something equally convenient but made of simple > > components. > I really don't know how you come to such a conclusion. > The original docstring of `pcase' was half of a screen page and it was > _complete_. Syntax and semantics are simple, nearly trivial, and > consistent. It took one minute for me to learn everything. Then the > doc has been extended to the current form adding more prose, in my eyes, > it added not a single bit of information. The original doc string of pcase was not a high quality one. See the thread in emacs-devel Subject: The poor state of documentation of pcase like things, started by me on 2015-12-16. Some of its deficiencies, listed in that post, were (i) Use of obscure terms like U-pattern and Q-pattern which it failed to define; (ii) the semantics of these structures was not elucidated; (iii) there was no rigorous definition of what ` and , mean in pcase structures; (iv) there was no specification of when a pcase pattern matched something; (v) there was no specification of when and how variables got bound. The doc string didn't say in accessible language what pcase does. But I'm repeating myself. It's all in that 8 year old post. I may be mis-remembering, but I think it was you, Michael, who put in the work to fix these defects in pcase's doc string. The result was far better than the original. > If some people have a problem understanding the abstract approach, this > is something different. But a "kludginess of pcase's > bells-and-whistles-for-everything approach" does not exist. So please > understand that your approach will make the situation worse for others. > To me this discussion looks like some people aren't willing to accept > multiplication like 10*5 because it "looks strange" and "one would rather > write "5+5+5+5+5+5+5+5+5+5" because this would be much simpler and we > don't need this strange "*" at all. > Is this unfair? I don't know. But are there any _objective_ reasons > why the design of `pcase' would not be optimal? To me this all looks > more like being based on vague feelings because the approach is a bit > different from what people are used to. But the approach is extremely > simple. I think that replacing it with multiple other tools would > complicate the matter. pcase complicated the meaning of ` and ,. Before pcase these had definite meanings. Afterwards, they became highly context dependent. The usual evasive reply from pcase proponents here is that ` has always been an abbreviation for backslash and that didn't change. A lot changed, here. An alternative here would have been to invent new reader macros instead of complicating and ambiguating ` and ,. [ .... ] > Michael. -- Alan Mackenzie (Nuremberg, Germany).