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: Instead of pcase Date: Fri, 1 Dec 2023 20:27:50 +0000 Message-ID: References: <763f067b-4ca9-1eba-9f3c-424c38589e9c@gutov.dev> <83fs0navpj.fsf@gnu.org> <87il5jgf1z.fsf@web.de> <83a5qubfud.fsf@gnu.org> <87plzp53h4.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="24893"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Michael Heerdegen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Dec 01 21:29: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 1r9A8D-0006B1-52 for ged-emacs-devel@m.gmane-mx.org; Fri, 01 Dec 2023 21:29:01 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r9A7C-0005qd-UW; Fri, 01 Dec 2023 15:27: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 1r9A7A-0005qB-OM for emacs-devel@gnu.org; Fri, 01 Dec 2023 15:27:56 -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 1r9A78-0000uK-98 for emacs-devel@gnu.org; Fri, 01 Dec 2023 15:27:56 -0500 Original-Received: (qmail 67619 invoked by uid 3782); 1 Dec 2023 21:27:51 +0100 Original-Received: from acm.muc.de (p4fe15fc1.dip0.t-ipconnect.de [79.225.95.193]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Fri, 01 Dec 2023 21:27:50 +0100 Original-Received: (qmail 30086 invoked by uid 1000); 1 Dec 2023 20:27:50 -0000 Content-Disposition: inline In-Reply-To: <87plzp53h4.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:313452 Archived-At: Hello, Michael On Fri, Dec 01, 2023 at 16:47:51 +0100, Michael Heerdegen via Emacs development discussions. wrote: > Eli Zaretskii writes: > > > This is not a valid expression and will be rejected by the reader. > > > Was it a typo or did you think this would be valid? > > It was taken from one of the posted examples, perhaps with a typo. > > But that is not relevant. > My question was meant sincerely. Did you try to understand the syntax? > How? What was or is still unclear to you? > > Are you saying pcase doesn't have > > constructs like (`(SOMETHING...), or that SOMETHING doesn't use > > periods in places where they are redundant in "normal" ELisp code? > Redundant - no. May there be different redundant ways to express lists > - yes. > If you use a backquote pattern `SOMETHING in pcase, when SOMETHING > should match a cons (lists are conses), then SOMETHING will typically be > a cons. The dot reader syntax is the canonical read syntax for conses. > This is not that weird. For some reason, I have little difficulty with dots in normal code, but have more difficulty with dots in pcase patterns. They must be being used differently. > > IOW, these details are not the point, the point is something else > > entirely, see below [...] > > My point focuses on the problems this syntax causes to someone who > > doesn't have intimate knowledge and a lot of practice with pcase. > It is repeatedly used a wording like "magical", as if that was an > argument. Ok, this syntax makes one first wonder how it has to be > interpreted. Happened to me, too. But this (the wondering) takes only > seconds. It took many hours for me. > What happens after that? Have people then seriously tried to > understand the syntax? Where and why did they fail? I heard nothing > about that. Just a repetition that it looks "strange" or "magical" or > that one would expect a different syntax. The syntax is confusing. Before the introduction of pcase (without any public discussion, as far as I can remember) a backslash meant what it meant, as did a comma. Now, if there are pcase's around I can't look at code and see what it means. For each backslash or comma, I've consciously got to stop and inspect it to see whether it's a standard b or c, or a pcase b or c. They tend to be mixed up indiscriminately. Also, special forms which had a fixed meaning have now become ambiguous - and and or. Again, it takes conscious inspection to determine whether one of these has its standard meaning, or the very different pcase meaning. > Given that cons cells and lists are fundamental building blocks of the > whole language, I had hoped to hear more about why understanding this > would be hard. Nobody did that concretely apart from Richard. And it > might be the case that his rewrite will reuse the backquote syntax. See my previous paragraphs for part of the problem. > > > As an alternative one can have a look at the docstring. > > It is a disadvantage if one needs to consult doc strings all the time > > while reading code. And in this case, the doc string is quite long > > and highly non-trivial (and rightfully so, since the DSL is a rather > > complex one). > This is, or should, not be the case. Sometimes one might need to recall > the argument order of 'let' or 'app', but more when writing code. > I don't ever need to consult the documentation of `pcase' when reading > code, apart from the case when additional pcase macros are involved > (like 'map'). And I don't have a good such a good memory for such > things. I don't have a good memory for them, either. When I have to read code with pcase stuff in it, I can't read it fluently. My consciousness is continually having to guess what the various constructs mean, which is demoralising. I don't have this problem with non-pcase code which is otherwise of the same difficulty. > And I use it only in rare circumstances, where possible I prefer `if', > `cond', and `if-let'. I only use it when maintaining other people's code. > > If one bumps into such constructs very frequently, then eventually one > > will become familiarized with them. But if the frequency is low > > enough, one could easily forget the details, and then one will need to > > consult the documentation again the next time. > What I want to say is that if you need to consult documentation of > backquote syntax in pcase again and again, you might not have understood > it entirely. This is my question: do people fail to understand the > concept, or don't they even try? It's not the concept, it's the details. The documentation for pcase on its own is probably bigger than that for all the standard Emacs Lisp flow control constructs put together. Another thing about pcase is that you can't usefully learn and use just part of it. It's all or nothing, and it's a terrific effor to learn at once. I don't recall anything like this difficulty learning, say, regexps. It also contrasts with something like German adjective endings, where one can usefully learn, say, just those for the three forms of nominative and accusative, and gradually extend one's fluency, say, when a dative ending becomes needed. > > Please don't underestimate these difficulties, even if you don't share > > them. > I still try to understand them. Yes. I hope I've done something to increase this understanding with this post. > Michael. -- Alan Mackenzie (Nuremberg, Germany).