From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Code for cond* Date: Sat, 03 Feb 2024 01:09:26 -0500 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="35989"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: emacs-devel@gnu.org To: Richard Stallman Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Feb 03 07:10:29 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 1rW9ER-0009A3-VS for ged-emacs-devel@m.gmane-mx.org; Sat, 03 Feb 2024 07:10:28 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rW9Db-00055J-Oi; Sat, 03 Feb 2024 01:09:35 -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 1rW9Da-000558-Eh for emacs-devel@gnu.org; Sat, 03 Feb 2024 01:09:34 -0500 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rW9DY-0005IB-Ew; Sat, 03 Feb 2024 01:09:34 -0500 Original-Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id EF8171003AF; Sat, 3 Feb 2024 01:09:28 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1706940567; bh=UJhg6tMwmrq/To7Eao+HXhipJdAIZmPgbKFImB1Fqbs=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=R0yr4rIcymdQAsF6RDHHR/yi8mAA3/eZEwmwGuXpTJfn0x6tyjQ/7TTQtZQyLQ1Qx /pAXsj0Ho8GEJVY6alIzQupI26iLJADsciOi+U4kXuwjmjye7WJp7drerxCrE7WE6D aWh0tr5FZwyloHKE3ENA147il/NVSVMDIOrUr/rxtqBBGAsSBn9VbL14mSp7jw+TG6 jlchHouj1bTV/Mo7yM8WzoI64rIKeAVGGngM6W90HNCjep1zPTFofDK9wDYFUKa6ba L2Gb5NP13sx5De90I1k6tA17GvyvvSeVB+CwthH++7R7Hm+Jfh9oTUfxCmXVbUpBI0 fLTGV8J00oayQ== Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id D54FF1002F1; Sat, 3 Feb 2024 01:09:27 -0500 (EST) Original-Received: from pastel (69-165-153-17.dsl.teksavvy.com [69.165.153.17]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 7252F12020D; Sat, 3 Feb 2024 01:09:27 -0500 (EST) In-Reply-To: (Richard Stallman's message of "Fri, 02 Feb 2024 22:32:01 -0500") Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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:315786 Archived-At: > > As I said: in Pcase I moved some of the "built-in" patterns, such as the > > backquote, out of the core (using `pcase-defmacro` to define them > > instead), as a way to make sure that `pcase-defmacro` is indeed > > flexible enough. > > You're suggesting that I do this by exploring, but that's the hard > way. Harder than actually necessary -- since the real intention of a > macro facility is for defining other kinds of pattern _given the ones > that will be provided_. It's comparable to looking for axioms for > mathematics (or even just plane geometry) -- interesting, but there > was no need for the rest of mathematics to wait for this to work. What have it tried to implement using the macro facility you designed for your patterns? Have you tried to implement, say the `map` pattern we have in `map.el` or the `cl-struct` pattern? > I wouldn't want to use it without making it include the improvements > I've designed into cond*, and I expect that `pcase-defmacro' is not > capable of implementing constrained variables or `cdr-ignore'. Your expectation is incorrect. > That would require changing the pcase pattern code. I don't think so. The primitive patterns were carefully chosen so it shouldn't be needed. E.g.: (pcase-defmacro constrain (symbol exp) `(and ,symbol (guard ,exp))) Admittedly, for `cdr-ignore` it would take more than a one-liner, because it affects the interpretation of all the patterns within it (which makes its meaning somewhat unclear: should `(constrain x (null (cdr x)))` be ignored if it appears within a `cdr-ignore`?). It might be the case that a clean implementation would require some adjustments to the implementation of other patterns. The details would matter. > If you tell me the name of the function in pcase which is the entry > point for processing a pattern, with that starting point I might be > able to understand some of that code. I doubt it will change the > situation, but I will take a look. As I said, you don't need to know the internals, as shown in the PoC below. Which adds a `pcase*` construct to your `cond*`. It's used like your `match*` but with Pcase patterns. [ The patch also fixes some misuses of ";;; " which are reserved for sectioning and mess up `outline-minor-mode`. ] Also, BTW, I don't understand this behavior of your code: (macroexpand '(cond* ((match* `(c ,@d ,e) DAT) BRANCH1))) ==> (let ((d2624 DAT)) (if (and (consp d2624) (eq 'c (car d2624)) (append (cdr d2624) (list e))) (let* ((d (cdr d2624))) BRANCH1) nil)) Stefan diff --git a/lisp/cond*.el b/lisp/cond*.el index e40543ce393..d25bd858324 100644 --- a/lisp/cond*.el +++ b/lisp/cond*.el @@ -218,8 +218,8 @@ cond*-convert-condition ;; Then always go on to run the UNCONDIT-CLAUSES. (if true-exps `(let ((,init-gensym ,first-value)) -;;; ??? Should we make the bindings a second time for the UNCONDIT-CLAUSES. -;;; as the doc string says, for uniformity with match*? +;;; ??? Should we make the bindings a second time for the UNCONDIT-CLAUSES. +;;; as the doc string says, for uniformity with match*? (let* ,mod-bindings (when ,init-gensym . ,true-exps) @@ -235,6 +235,18 @@ cond*-convert-condition (let* ,mod-bindings (when ,init-gensym . ,true-exps))))))) + ((eq pat-type 'pcase*) + (if true-exps + (progn + (cl-assert (null uncondit-clauses)) + (cl-assert (or (null iffalse) rest)) + `(pcase ,(nth 2 condition) + (,(nth 1 condition) ,@true-exps) + (_ ,iffalse))) + (cl-assert (null iffalse)) + (cl-assert (null rest)) + `(pcase-let ((,(nth 1 condition) ,(nth 2 condition))) + (cond* . ,uncondit-clauses)))) ((eq pat-type 'match*) (cond*-match condition true-exps uncondit-clauses iffalse)) (t @@ -340,8 +352,8 @@ cond*-bind-pattern-syms (defvar cond*-debug-pattern nil) -;;; ??? Structure type patterns not implemented yet. -;;; ??? Probably should optimize the `nth' calls in handling `list'. +;;; ??? Structure type patterns not implemented yet. +;;; ??? Probably should optimize the `nth' calls in handling `list'. (defun cond*-subpat (subpat cdr-ignore bindings inside-or backtrack-aliases data) "Generate code to match ibe subpattern within `match*'.