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.bugs Subject: bug#72328: [PATCH] Nested backquote in pcase Date: Thu, 08 Aug 2024 08:57:11 +0300 Message-ID: <86jzgrmua0.fsf@gnu.org> References: <87jzh62vtr.fsf@gmail.com> <877cd5k1ra.fsf@web.de> <871q3d347e.fsf@gmail.com> <877cd4rxqo.fsf@web.de> <867cd4ywnq.fsf@gnu.org> <87mslumpsw.fsf@gmail.com> <86msluuox9.fsf@gnu.org> <875xshn3km.fsf@gmail.com> <87cymo6wp9.fsf@web.de> <87v80gkmg7.fsf@gmail.com> <86ikwfqj9w.fsf@gnu.org> <87a5hqzrxg.fsf@gmail.com> <86o765q4yo.fsf@gnu.org> <871q31ztju.fsf@gmail.com> <87bk2580rv.fsf@web.de> <87msloxmmv.fsf@gmail.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="7025"; mail-complaints-to="usenet@ciao.gmane.io" Cc: michael_heerdegen@web.de, monnier@iro.umontreal.ca, 72328@debbugs.gnu.org To: Thuna Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Aug 08 07:57:54 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1sbw9q-0001eB-3Y for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 08 Aug 2024 07:57:54 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sbw9b-0007Fz-Pw; Thu, 08 Aug 2024 01:57:39 -0400 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 1sbw9Z-0007FR-Lh for bug-gnu-emacs@gnu.org; Thu, 08 Aug 2024 01:57:37 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1sbw9Z-0007en-Cx for bug-gnu-emacs@gnu.org; Thu, 08 Aug 2024 01:57:37 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=References:In-Reply-To:From:Date:To:Subject; bh=ZmD+HS++Lzhy+64/F7RcWrC8+BrMNSvS6SHEDZ+hGlM=; b=dGFJ/0I9Zm5laDEkvyFKV4i2p6DlaY7K81bqRzlRo7QLga+3t5KeFQvXV7ywXNl66v4aUjiiRN7bPIkOvInxbPrr9hT226OAzaVTa6Qt9PLHSYvUZNlnH8ummrDB6FHLFxIeNisiwBHqg+dx+KXA68F5IRU7MPcZCGfadQhyzXWbUtcjpuAH/UqOUW1EaI2jCDoDYuHCIGm4/U6XsVegmy3ClyZ20k3lQEWpQxSaWLDCSoJlRviMnb/ReI9ehBXRReQD9OdVVIqoGNnU2GtA5BWR6mycT8nD/MsXBA+YvRNZG/YYm36dl7a3aZEUJmVEVksiabHhnPOiWaoBbBOKRg==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1sbw9y-0007s6-Fg for bug-gnu-emacs@gnu.org; Thu, 08 Aug 2024 01:58:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 08 Aug 2024 05:58:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 72328 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 72328-submit@debbugs.gnu.org id=B72328.172309666930239 (code B ref 72328); Thu, 08 Aug 2024 05:58:02 +0000 Original-Received: (at 72328) by debbugs.gnu.org; 8 Aug 2024 05:57:49 +0000 Original-Received: from localhost ([127.0.0.1]:35350 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sbw9k-0007re-Rd for submit@debbugs.gnu.org; Thu, 08 Aug 2024 01:57:49 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:41534) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sbw9h-0007rP-QA for 72328@debbugs.gnu.org; Thu, 08 Aug 2024 01:57:46 -0400 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 1sbw9B-0007cY-Rp; Thu, 08 Aug 2024 01:57:13 -0400 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=ZmD+HS++Lzhy+64/F7RcWrC8+BrMNSvS6SHEDZ+hGlM=; b=a2z4qiCFOEGW pGtqRKJLle6cH8SUVjNS25UdW6DlY6tJBZhzdFDc3K/ALQaHSqDx3lOicsujhgFPFjiQt38yeCVaM uzxSMfhdDAXdvY/NJUwKav9YjbEtxC6ah8u+hF4ksBBdxmu0I4Tx4DAHEZp9kCHpKvaGrDwNCcZP0 Bl7643+afUIbalkGpdjKbhEHEzf/Jbrk1JLcqW6HJXuj/7GXUe0swu5rklV9j2TR+BUe+vEh+DFJG y/i29TdVnfab6qCSCrtTvj8fzAJAUh7WefUClQa6ifGqLXSWgSCGqX3b0CxWeyFpJxYuXcKACxgVj qXJHDUtq9c2qH3g/59oB8g==; In-Reply-To: <87msloxmmv.fsf@gmail.com> (message from Thuna on Wed, 07 Aug 2024 19:34:32 +0200) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:289914 Archived-At: > From: Thuna > Cc: Eli Zaretskii , monnier@iro.umontreal.ca, > 72328@debbugs.gnu.org > Date: Wed, 07 Aug 2024 19:34:32 +0200 > > What I question is not Eli's intentions or reasons, but the consequences > of complying with those requests: I fear that the moment I start > defending and giving justifications for the existence of macroexp-null, > this report will forever be reduced to just a "companion patch" whose > sole purpose is to make a later patch *look* nice. My concern is that > this will end up the same way me showing no code in melpa would be > effected by this patch did - with my case being hurt on false grounds. You make it sound as if there's some hidden agenda in this discussion. There isn't. > I have evidently been unable to get my point across, so let me try to > explain it yet again: The "broader context" has no effect on the > decision to use pcase in macroexp-null, you might as well be asking my > why I used cond. I use pcase in macroexp-null because for pattern > matching it is by far the best tool there is and it makes for a much > more readable and extensible code than > > (defun macroexp-null (exp) > "Return non-nil if EXP will always evaluate to nil. > This form does not take non-local exits or side-effects into account." > (or (member exp '(nil 'nil #'nil `nil)) > (and (eq '\` (car-safe exp)) > (length= exp 2) > (eq '\, (car-safe (nth 1 exp))) > (length= (nth 1 exp) 2) > (macroexp-null (nth 1 (nth 1 exp)))))) > > Furhermore, even if the resulting discussion concludes that > macroexp-null should exist, that does not mean anything about this > change; I have already demonstrated that the program can be written > without it[1]. And the reverse implication is true: This patch can be > accepted without macroexp-null. In fact, it is a stronger implication: > This patch can be accepted without ever acknowledging the existence of > macroexp-null. > > Given these two are separate things that do not need each other, and the > example alone demonstrates the value of this new behavior in this > specific situation, the continued inquiry on a justification can only > bring about a single result: If I somehow fail to convince people that > macroexp-null should exist, this makes a case against this patch. The > opposite will not be true however (if I convince you that macroexp-null > should exist will you not simply tell me to use the version which works > pre-patch?). > > And let me also mention again why I think that this is a genuine > improvement: You currently cannot match against a nested backquote > object in any sane way. The pattern you need to match against the > unevaluated form ``(,,) is > `(,'\` (,'\` (,'\, (,'\, ,(pred integerp))))) > and... how is this not considered a problem? That this thing works at > all can only really be thought of as a coincidence, and it explicitly > relies on `foo being (\` foo), which I would personally consider an > internal implementation detail not to be used by outside code. > > There is a genuine loss with switching over to the new behavior: We run > into the same issue as before when matching against an unevaluated form > ``(, ,,). > > This is also why I want to have more discussion about the patch itself: > The current behavior is bad at actually matching backquote objects as > obtained by a single quasiquote macro, but the proposed behavior is bad > at matching backquote objects obtained by multiple different-but-close > quasiquote macros[2]. It is very likely that the result of that > discussion will end up changing the way this patch actually works and > maybe even result in the original behavior being maintained in the first > place. I think we all agree that your suggestion has some advantages in some situation. We also all agree that the problem you are trying to solve is solvable already by other means, so it isn't like the problem doesn't have workarounds, and the workarounds are not in general terribly kludgey or inconvenient. So justification for introducing such change in behavior is actually the main point that needs to be discussed, because it will be a main factor in the decision whether we want to install such a change. And the justifications that we are interested to hear are the situations where using the available behavior would cause such significant inconvenience or unclean code that having this new behavior would avoid. Then we will have to decide whether those situations are important enough for us to risk the incompatibilities, complicate the documentation, add backward-compatibility shims, etc. -- all of which make Emacs slightly more complex and slightly harder to maintain. This process and these considerations are inherent to the maintainers' decision process when a change is proposed that means incompatible behavior changes in Emacs. Talking about the advantages alone doesn't cut it.