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: Wed, 31 Jan 2024 08:20:03 -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="26367"; 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 Wed Jan 31 14:21:10 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 1rVAWc-0006b7-HY for ged-emacs-devel@m.gmane-mx.org; Wed, 31 Jan 2024 14:21:10 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rVAVk-0001Gv-B8; Wed, 31 Jan 2024 08:20:16 -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 1rVAVi-0001GM-9P for emacs-devel@gnu.org; Wed, 31 Jan 2024 08:20:14 -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 1rVAVg-0006rn-79; Wed, 31 Jan 2024 08:20:14 -0500 Original-Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 62D9C10009F; Wed, 31 Jan 2024 08:20:09 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1706707203; bh=mQ2uj4fFqx+ZKmRpcPvOIhgENb7UUb1t/Tq+N+EfWNc=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=MI4o2JWH9YBZHPJOkN932IvnxhOFkbFRRkD6u5PqvbIFkF4Jvg3Tl0S2m/R7XuiJl kmqYN5dQlWGT+TMpYnG28KhErXoHRyWm0NBwfmjfR9sFIOHWm1cKIVMt4hK+j22KGa xQUXsglIY+uQjgeTCTuerfiFfAthJtvvyvgDXLVEfaHuScc1/k0RHYea7ibduT9Qg2 IF0xFSd7m0n4mINhURqHJ3o3GLnRjvhkntt5YSCfN5b9BEk4kc3zK8TxYVcMHcI8tb lVq5n+y+N2L6MmS8kgV/gySqRrN0BFbnqThpD50rLPXQi9jhiP3yjfr4x4FqoJja5R FpkEF5IN2jMsA== Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id E418210004C; Wed, 31 Jan 2024 08:20:03 -0500 (EST) Original-Received: from pastel (104-222-119-131.cpe.teksavvy.com [104.222.119.131]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id C4C1D120B88; Wed, 31 Jan 2024 08:20:03 -0500 (EST) In-Reply-To: (Richard Stallman's message of "Tue, 30 Jan 2024 22:32:42 -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:315664 Archived-At: > > Is this what you're referring to? > > > ((get (car subpat) 'cond*-expander) > > ;; Treat result as a subpattern. > > (cond*-subpat (funcall (get (car subpat) 'cond*-expander) subpat) > > cdr-safe bindings backtrack-aliases data)) > > > do we have reasons to believe that it's flexible enough? > > Nobody is actually using this now, so now is the best time > to make changes -- perhaps to make it somehow more flexible. > But I have no concrete idea of what flexibility you wish for. > > Can you make a concrete suggestion? Then I might understand. 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. [ And indeed, I couldn't have done that with the first version of Pcase because of the lack of `app`. ] You could do worse than trying to do exactly that for your patterns. Tho better would be to just give up on your pattern language and (re)use Pcase's machinery instead. Less work, less code duplication, less documentation duplication, less to learn for coders. And presumably you'd then improve Pcase, so everyone wins. Stefan