From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Michael Heerdegen Newsgroups: gmane.emacs.devel Subject: Re: Instead of pcase Date: Sun, 19 Nov 2023 13:23:17 +0100 Message-ID: <87zfza2aq2.fsf@web.de> References: <87fs169mjj.fsf@posteo.net> <093f11a1-57c2-5e56-d39b-26fef1c67cbb@gutov.dev> <25942.25061.217864.329049@retriever.mtv.corp.google.com> <87zfzdcz6z.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="8555"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Philip Kaludercic , emacs-devel@gnu.org To: Richard Stallman Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Nov 19 13:23:40 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 1r4gpw-00025G-FW for ged-emacs-devel@m.gmane-mx.org; Sun, 19 Nov 2023 13:23:40 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r4gpT-0007IA-EF; Sun, 19 Nov 2023 07:23:11 -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 1r4gpR-0007Hn-AH for emacs-devel@gnu.org; Sun, 19 Nov 2023 07:23:09 -0500 Original-Received: from mout.web.de ([217.72.192.78]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1r4gpP-0001A8-EV; Sun, 19 Nov 2023 07:23:09 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=web.de; s=s29768273; t=1700396583; x=1701001383; i=michael_heerdegen@web.de; bh=AYU8mghXL+Rs2wSH+QVPctPJ4Z03oAnLs7z8hnUv1Tg=; h=X-UI-Sender-Class:From:To:Cc:Subject:In-Reply-To:References: Date; b=STx8WZ0Z7Qtq2DjuUnDgITRvD88K+Vkdrjh5UZhmOKX1nyq7M/L1cBNxtDw6sqtx 12JQDEdd8zYVFF41IQ6dAVDoSEJrLGNwHUQ3cF0PnzJwIqvB1AHaB281IBB7CKLvD DC8BBeXp2wYR1vb9xD6z99hEJ0i9akL4kT2YUm7ABNCDJUGibnhz3eoqHrJ4T01xv HbgY69CpeTO3SSpJgbAokTgIDLi7Mfrq212dtJCXiAyOyMQ5lelPOFjx8s7OXbphv CnCWxLAJ6L2VxmTVWpFCvwrx7lTHazRfqZ079JJoYxtXB3BH4+3x2K9DnhnVfCkiX cBxlztAUwHOB57oLmQ== X-UI-Sender-Class: 814a7b36-bfc1-4dae-8640-3722d8ec6cd6 Original-Received: from drachen.dragon ([178.6.28.177]) by smtp.web.de (mrweb106 [213.165.67.124]) with ESMTPSA (Nemesis) id 1M8kAN-1r00063CjJ-004TYO; Sun, 19 Nov 2023 13:23:03 +0100 In-Reply-To: (Richard Stallman's message of "Fri, 17 Nov 2023 22:04:14 -0500") X-Provags-ID: V03:K1:uix9SAsIFqmgtkDli9AsT4GEx3avLzpR9YhzpPlJGSn0RwLrKEm HbHMTwhYNIA6lHznCwzrzfL+iyDzFFb3VNlmwtA6o+xgKBm5cIWHugqUJC/2/cgAAFPc92h 92XZ0jcm4un1X//Eg2I74apKW+qRb/XKUQxQGYmQPCHc6VEEA5lq0wZ7ws7tOndN/9tMQ7O ZM4AW9LozRy1bD+e6muaw== UI-OutboundReport: notjunk:1;M01:P0:a3kBwqDbHyI=;Nxq2eCkejCVMWt6e0iqvVYq79qe IsUKb9rTseAzvOYDuA5sfF2GrPB969X7C5QVAgqe3OfKEKBhLRZb279TmgxdsdIJ6Wd6pdcI2 rNaTzI66wbwuIunYsfbEASxXxn1qDz92s3va7I6OvvxHgDyIDmJwzDh6INyYDN6g33ZA1wHLU JtlRRP39dpf8hsr60cqDPFyB5q/fzYqvrjOV/qtU778oUqlybdQezd92JboH6avNixwr9ugQp gaZnNoVrxhCOL4lM5iscBmaVoADX3BNyIKcdg0/60OwA92DR5abu/zd7jx0FrbiiKLTR/OX1C vyxDxCod1lPkoIGoH43p0pfB4/Tova3U8PRe1ntAbQ1/D4y4LmOGLK7jpb6hBt4J3vgmG1SKR xLYmugW7M3SEOvsZZMYIEyeyVaZJFf226geob6ABIaWv+P/DhWbBsR4+Rk8utzzFQ2nz4pLHg tNcm64PGzhzuaxzzffkvZG/b5G2vtbE/b+eUPv0D+LGw4qsJlQKk3I9Klecneza1N2Omuj4Zt 7dWwW2ybvei+1OTycMwwfm/sNy8dU5MYauGfn94d25wEnnCO5UEIvGCrdzKAOq10lmZw6XjcF d9NxGsRGMRK2IJCkql905Z9tSN/KnusfQNiWwdvvgcnF9WFL82Z44OkEjPVQVRYgvcE9Dp4C5 YuQm+O/XDHLoTFRpeCGGz7PPLlnKeWd0phKRWE+vseJJCkOHZPA5cAnjsPG9/jE2khbtCO8gk Z4nxneXU8xd13wpSh1KecR0+lvzqE1MwTng1mKkIZu9XOmEO8HdsNfWQibPY+WKxvhKwWZ3J Received-SPF: pass client-ip=217.72.192.78; envelope-from=michael_heerdegen@web.de; helo=mout.web.de X-Spam_score_int: -37 X-Spam_score: -3.8 X-Spam_bar: --- X-Spam_report: (-3.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=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:312968 Archived-At: Richard Stallman writes: > I read the Info documentation of pcase a few days ago and I can't > recall the rules for understanding those two pcase clauses. What I > recall is that they are not to be interpreted as Lisp expressions. > They contain code that looks like Lisp but does not have the same > semantic rules as Lisp. > > `(,_ . ,(and (pred functionp) f)) > > is not Lisp. > > `(,hookfun . (,start ,end ,collection . ,plist) > > is not Lisp either. I more and more come to the conclusion that the backquote syntax is more or less the central point that scares or confuses (some) people. So you would rather prefer to have a normal function that returns a matcher (if you want just "Lisp")? What functions could be used to describe a pattern matching lists of a certain structure? I guess it would be the easiest approach if we could still use the names we already know: list, car, cdr. Hmm - actually the most compact mean to construct more complicated lists is backquote. And that's what you have above. The only thing you need to remember is that elements you "insert" or "splice in" are again pattern descriptions matching the elements at that position. How could it be even simpler? Once you accepted that backquote is used for a different, but parallel semantics here, everything suddenly gets absolutely trivial. But I see your point, it's not Lisp. I guess it should be possible to change that. We could define a set of functions to construct a matcher. This would make the pattern specifications less compact and for some of us harder to read (more verbosity), but it should be possible. We could even have some kind of converter between the two representations of pattern specifications. This leads me to a realization: A "normal Lisp" approach would still need to define replacements for all of the constructs. (pred FUN . ARGS) would have to be replaced by something like (make-matching-fun FUN &optional ARGS). You would still have to remember the exactly same details: what are the semantics of the returned pattern; when there are ARGS specified, at which argument position is the matched thing specified when FUN will be called? How to correctly negate this pattern? Will the matching algorithm backtrack when the pattern is negated? So, the advantage would be more of a psychological kind: you have normal Lisp function calls, but structurally you have the same thing, and you have to remember exactly the same set of details. The complexity comes from the task, not from the implementation. Michael.