From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Instead of pcase Date: Sun, 19 Nov 2023 17:09:57 +0200 Message-ID: <83msv9kce2.fsf@gnu.org> References: <87fs15kkk1.fsf@yahoo.com> <874jhi3qx3.fsf@web.de> <83y1etkiuq.fsf@gnu.org> <87jzqd3k4d.fsf@web.de> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="40529"; 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 Sun Nov 19 16:10:47 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 1r4jRc-000AGG-JF for ged-emacs-devel@m.gmane-mx.org; Sun, 19 Nov 2023 16:10:45 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r4jRP-0005xC-Pv; Sun, 19 Nov 2023 10:10:31 -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 1r4jRL-0005sI-5j for emacs-devel@gnu.org; Sun, 19 Nov 2023 10:10:27 -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 1r4jRK-0001SY-80; Sun, 19 Nov 2023 10:10:26 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=WlDooYgfFPxeJ//Vt34hqVa1LzPj6TV1fBOl8TWqsgE=; b=pz8rFvhx5Chb 5YWaa9QhRLIaAzXTQtqL41qvU3JzEmhe0eAjc8tdiO0SLFkSbSYeFRmbJpqQPUg1OE/i0E7IQkXvG QpFviHn1XWlxmY1bag0OEbBjXXfgHN7+vdZyI7xLcZ9Jcp43SP+dlmWxvBB7fLshXHDdV0u96RYib A0n+RP0Su1Nw/HOIIcP2/8krF6ok6J648u8hbTZhD+yzuj5Z/jXoXiJIh7qz9KwkxjDmmw93bNgFa w0iFtOlHbPiqSAA7yWUDDLuzofR0Sod789Tey2BewbRE2zxOuPOGXcZJWV1y7PLgxTjF6JIuqad1Y S1EP71gYEVemJSKTjsPDIw==; In-Reply-To: <87jzqd3k4d.fsf@web.de> (message from Michael Heerdegen on Sun, 19 Nov 2023 15:14:58 +0100) 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:312993 Archived-At: > From: Michael Heerdegen > Date: Sun, 19 Nov 2023 15:14:58 +0100 > > I'm curious how an alternative could look like, actually. I don't know. So I withdraw my judgment until such an alternative is presented. I suggest that everyone do the same. > It would have to implement the same set of features, so it would be > quite as complex as `pcase'. Complexity doesn't necessarily mean cryptic syntax. Cf regexp strings vs Rx. Cryptic syntax raises the bar by adding one more obstacle: before you deal with semantic complexity, you need to fight the uphill battle of syntactic complexity and obscurity. > You would have to remember or look up more or less the same things > and details. But if "the same things" speak for themselves, because they are identified in more human-readable language, you have fewer things to look up. Again, cf. regexp strings vs Rx. > And here the `rx' example and `pcase' are very similar: what the > programmer actually has to keep in mind is how the regexp matching > algorithm or the pattern matching algorithm works. That's true, but before you consider the subtleties of matching, you need to understand what the regexp should match, and that is harder with regexp strings when advanced features are used. > In your example, actually, string regexps are the primitive, low level > language, `rx' is the higher level language, so it should lead to less > mistakes (your argument). `pcase' is the extensible higher level > language for pattern matching, specifically designed for this purpose, > so it should be more suited and lead to less mistakes than more > primitive tools. To me, whether stuff is lower or higher in level is less relevant here. For example, macros can be considered "higher-level" constructs than the underlying Lisp functions and primitives, but macros are harder to read due to the additional syntax: the backticks, the comma, the @, etc. I'd say that higher-level languages always make it easier to write programs, but don't necessarily make it easier to read them. As another data point, consider the C preprocessor macros and specifically their advanced features, like # and ##. I invite you to try reading what we have in src/conf_post.h and src/lisp.h, and make up your own mind. > Has anyone counted how many mistakes were introduced by wrong pcase > pattern specifications, compared to more verbose re-formulations using > other tools? If we don't do that, the discussion is still selective, > with other words, about preferences again. Should be good to do that, but please remember that pcase exists for less than a decade, so we are just starting to learn to use it.