From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Thuna Newsgroups: gmane.emacs.bugs Subject: bug#72328: [PATCH] Nested backquote in pcase Date: Wed, 07 Aug 2024 19:34:32 +0200 Message-ID: <87msloxmmv.fsf@gmail.com> 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> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="7808"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Eli Zaretskii , monnier@iro.umontreal.ca, 72328@debbugs.gnu.org To: Michael Heerdegen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Aug 07 19:37:03 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 1sbkas-0001qz-9a for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 07 Aug 2024 19:37:02 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sbkaY-00058r-5A; Wed, 07 Aug 2024 13:36:42 -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 1sbkaT-00058d-D9 for bug-gnu-emacs@gnu.org; Wed, 07 Aug 2024 13:36:38 -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 1sbkaT-0006eN-0O for bug-gnu-emacs@gnu.org; Wed, 07 Aug 2024 13:36:37 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=MIME-Version:Date:References:In-Reply-To:From:To:Subject; bh=L9PlBJApXykhNrdSYOPi41lyN0yUrcAdBN3Ae7kdUtw=; b=djrG4dMkBmZD3ZqzHr20M1vT4yeASGyGvTm5p4ItlBldIb/eYGGGKSkk4BoLq2FCHPT0NzeCwvqoaANSm8+LBIhzvE1ncrp4W6hac2IbypycrkkVimes/nXmYSygKb4qx7qrTzZzp+MRu1C5tDxEEQ2oQFFhs9OR/5MpOtQahquJOlsr63uELY8PLMH1K2O4/yT80mWLuVwApQd2twKfGHyvyjDK/y3GNWMbNOlUJ7SfvwYp/DvTzC4Ana56WVmQ18LG7AsY7/ebppCTH7JR75DEf5MILBIzTyoFtv/MFq1aHnzuZ3hW1biAWzhFM1SH6u/HFCgHqaaW3iCm8qPTpQ==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1sbkas-0005l3-D1 for bug-gnu-emacs@gnu.org; Wed, 07 Aug 2024 13:37:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Thuna Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 07 Aug 2024 17:37: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.172305218022071 (code B ref 72328); Wed, 07 Aug 2024 17:37:02 +0000 Original-Received: (at 72328) by debbugs.gnu.org; 7 Aug 2024 17:36:20 +0000 Original-Received: from localhost ([127.0.0.1]:35058 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sbkaB-0005ju-IT for submit@debbugs.gnu.org; Wed, 07 Aug 2024 13:36:20 -0400 Original-Received: from mail-wm1-f47.google.com ([209.85.128.47]:52225) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sbka9-0005jh-8k for 72328@debbugs.gnu.org; Wed, 07 Aug 2024 13:36:17 -0400 Original-Received: by mail-wm1-f47.google.com with SMTP id 5b1f17b1804b1-428243f928fso1384515e9.0 for <72328@debbugs.gnu.org>; Wed, 07 Aug 2024 10:35:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1723052085; x=1723656885; darn=debbugs.gnu.org; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:from:to:cc:subject:date:message-id:reply-to; bh=L9PlBJApXykhNrdSYOPi41lyN0yUrcAdBN3Ae7kdUtw=; b=Tglptbv23aohxdkvjYXLuNkpqmCRo40KJ5sKMyaPk3cOeMRxAXegopJBoCHMgUtp1U g3a10SwvwJ7ep9/Aw9F+sj88+8VPyCLoC6fZh5pGAugz45LyIBIjXNAyG8Izxko2oPzG rdy5pSYalDvS5A1Yyuib//q/ldR4Gk1zEZIpQaFxUUZnp7NVRFaA4PWGi9bdM6rC0D1S ryS0lGOk7UMnJdIzNBUf9xq9Fz4BKRv94++MPrFLnWDCEGppWmBI+0rzDa6StX+k/Agw j7h07mXpl2mxP3JTgn0jTiL+psZN2HMtOeMeklHSab9x9nXvQ00gudmPxqQmOzCKObFY vZUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1723052085; x=1723656885; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=L9PlBJApXykhNrdSYOPi41lyN0yUrcAdBN3Ae7kdUtw=; b=PHGe+6juWL56luZgobQH8gOXLAiYbgU81HRcbFFnzrZwTUcgAJwBZp1uim5KWbh/UI /b4c3CJobmkS2kfvSKXMEfJXX1XpRCDYEJX9kibgVKKJkM3BwlRMGV/MNiUFi/5qVqti XYdokIg62kvUu9D0CYzfmr1LQ2hr9S4Nt1zli0F2sFG1oEiXj5dBTP15iXO8GW6UtbJW 8wgotd5XmBkmsLkqEN1s5WEaRgY+bFkZMN2UgVale2LpyGt2r25J50cf1zw91GtAe+id VtoJJ0RMcN7tgv0VWFc5Lzh56t+HVjfbYD92eAcxGIAS8n/5MUaCwLAQSxf5K2oN7KKV znjQ== X-Forwarded-Encrypted: i=1; AJvYcCWYamGqDGvVI3hOKhaM+guPfJ+3JrtbTCSt1Wjj3jC44S1qwObqI8a9ms1dYOTWRLlMkUdDVszzJcQvJOuy23qec6MyXUs= X-Gm-Message-State: AOJu0YzpbMwHhAdH3eYJKykctiq2dZSILNQUDOGgn4uN5pSTCgFsStEb +qov92gdF+4nBF+jJqnYNpYzwAs1cu5vm/PS3RhCG22TF6Nd4eRgTvTQWq8P X-Google-Smtp-Source: AGHT+IEDxbDGpa8oIucGFW6OSdPB0kGrvxWIGNF9XPhCahcZl5FmgxX1qBJ0ZrB8XPhF7SiimfJTbA== X-Received: by 2002:a05:600c:35ca:b0:426:545b:ec00 with SMTP id 5b1f17b1804b1-428e6b2f0c5mr174185585e9.19.1723052085161; Wed, 07 Aug 2024 10:34:45 -0700 (PDT) Original-Received: from thuna-lis3 ([85.106.105.81]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4290579f58esm39453165e9.11.2024.08.07.10.34.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 07 Aug 2024 10:34:44 -0700 (PDT) In-Reply-To: <87bk2580rv.fsf@web.de> 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:289902 Archived-At: >> I don't see how we can discuss whether this patch has enough benefits to >> clear the hurdle of backwards-incompatibility if you are not willing to >> engage with the discussion of what this patch's benefits *are* to begin >> with. > > He sees that of course, but it is not what he has asked for because it > is obviously not enough. It may not be enough but it is a necessary step. I am currently having to caveat all usage of the word "improvement" with either a weakener like "IMO" or a conditional like "if this is considered an improvement". Having to repeatedly try to appease implicit, unstated, and unchallangable contentions is rather tiring. > So I suggest to avoid meta discussions about what we expect and > how others should behave and, even if it sucks, try to answer Eli's > questions without questioning his reasons and intentions all the time. 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. 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. [1] With or without pcase, though in this instance I am referring to the with-pcase version I provided in my previous messages. [2] You can only obtain an unevaluated form ```(, ,,,) via an evaluated form like ````(, ,,,,) where is a fixed symbol. If the pcase pattern is matching against all possible objects, that means that the objects it is matching must be coming from different quasiquote forms.