From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Richard Stallman Newsgroups: gmane.emacs.devel Subject: Re: Installing cond* in core Date: Mon, 29 Jan 2024 22:58:38 -0500 Message-ID: References: Reply-To: rms@gnu.org Content-Type: text/plain; charset=Utf-8 Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="37875"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Jan 30 04:59:02 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 1rUfH3-0009eD-KG for ged-emacs-devel@m.gmane-mx.org; Tue, 30 Jan 2024 04:59:01 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rUfGk-0008F9-K1; Mon, 29 Jan 2024 22:58:42 -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 1rUfGh-0008Cd-7D for emacs-devel@gnu.org; Mon, 29 Jan 2024 22:58:39 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rUfGg-0001IF-Ob; Mon, 29 Jan 2024 22:58:38 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=Date:References:Subject:In-Reply-To:To:From: mime-version; bh=etKHFPiMgLCor3lqYL9IO41CVBGnoB95Jd393ogQomo=; b=Gly1XYjlEKEe 2KAmk6NeY8zq1afLOYS3pnOJNSq1IA8ybOzVEvlWW7xN6f+cLKgmq81dQq2dROg4CykSPvPxTFMME GC5uZpmUncYc0W30y0y/cTUhyu27SX7HjKz8p8rF8XK/635CO1PXLqqKo0HkUjEmpnUXWgxbohhzK p7Q3DN6g/I66rAoDbb4ybRzYKGgUe4XK6yCcTBJCLXqGskA1A+y4KzExn3oJNi8pXjTuy1KIuNq3q 8cqUUQEnGUIkF1swRHoi2UjSeJi/r4/J57F4EvciQ76Y0WpUcGX/X+bXcPKiicfQpmMDNcwOgOcCv UvbCLhPdAAppIUA6UQsY3Q==; Original-Received: from rms by fencepost.gnu.org with local (Exim 4.90_1) (envelope-from ) id 1rUfGg-0000VG-Cq; Mon, 29 Jan 2024 22:58:38 -0500 In-Reply-To: (emacs-devel@gnu.org) 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:315628 Archived-At: [[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > But I think the two pattern languages (that of `cond*`s `match*` and > that of Pcase) need to be unified, because they're already too similar > to justify having them both. This would be a very simple change that > simplifies the implementation (and the doc) significantly. When I started designing cond*, I wanted to make its pattern language more different than it actually is. Especially I found _ to mean "match anything and ignore it" to be clunky. I wanted a simpler way to say that. For cdr slots, I found a much more convenient way. But not for car slots. I could not find anything else distinguishable that was simpler or better than _. So I went with _. I did manage to simplify the `pred' and `guard' constructs, replacing them with constrained variables. I changed some details of `rx', but that was to make it easier to implement. Indeed, it simply calls the Lisp facility `rx'. Aside from `app', which cond* does not need, is anything else missing (as opposed to, not yet implemented) from cond* patterns that pcase has? For now, I will assume not. So, how could we make the two pattern languages compatible? For `rx', I don't object to changing cond*'s `rx' to be compatible with pcases's. But I don't want that to implement that myself, because I expect it to be a pain. I don't know the pcase code so I can't undertake to make cond* use that. Can someone else write this change in cond*? For constrained variables, the path I'd be happy with is to make both cond* and pcase implement both pattern interfaces. That means cond* constrained variables (both kinds) and `pred' and `guard'. I could write that change in cond* if someone else writes the corresponding change in pcase. -- Dr Richard Stallman (https://stallman.org) Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org)