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: Fri, 23 Aug 2024 22:19:25 +0200 Message-ID: <87wmk7hu0i.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> <87msloxmmv.fsf@gmail.com> <86jzgrmua0.fsf@gnu.org> <87v7zrncmw.fsf@web.de> <86plpzp6oc.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="12890"; mail-complaints-to="usenet@ciao.gmane.io" Cc: michael_heerdegen@web.de, 72328@debbugs.gnu.org To: Eli Zaretskii , Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Aug 23 22:21:34 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 1shamq-000385-V7 for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 23 Aug 2024 22:21:33 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1shama-0004r4-6b; Fri, 23 Aug 2024 16:21:16 -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 1shamZ-0004qu-4U for bug-gnu-emacs@gnu.org; Fri, 23 Aug 2024 16:21:15 -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 1shamY-0000O7-Rh for bug-gnu-emacs@gnu.org; Fri, 23 Aug 2024 16:21:14 -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=S5CIaq8tV1zoGOjSEQd3BTJ3IsrHPVhL7N0NIKX+AD4=; b=mj1d14qjAfbfZh70BPszhyy7YfCRJAWAgjVCq0mQ2I5cNbiIvcDh027UXZg9rV+dWSJ5O92kwQbORkQKejTbPeyFlLeRFUedFHehQN6BFlgdX1gKFOrFxsqo6pb08SK/y+0lyWIoJacfWTZVZesvqnNC2aVJMDqB1Fv2/lzSXBWiJC1T+MNjyAvzYwrCspqw17oJ6oFKisvHRcckwQ+B+r2Cd7pMYplMronC7tHR1ICTb2wtu7+hvD9fL+r+BYVpFtdyWP5L4wvMF9pWXtl6G4JY/qclaYt6T8SVBLmZaopMZfkOHtdDwk57RKnAnzthW7DuIfLXUmfU5+AkwRdtbg==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1shanK-0003ga-CB for bug-gnu-emacs@gnu.org; Fri, 23 Aug 2024 16:22:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Thuna Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 23 Aug 2024 20:22: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.172444448514094 (code B ref 72328); Fri, 23 Aug 2024 20:22:02 +0000 Original-Received: (at 72328) by debbugs.gnu.org; 23 Aug 2024 20:21:25 +0000 Original-Received: from localhost ([127.0.0.1]:40163 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1shamj-0003fF-0s for submit@debbugs.gnu.org; Fri, 23 Aug 2024 16:21:25 -0400 Original-Received: from mail-wm1-f44.google.com ([209.85.128.44]:46407) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1shamh-0003ez-9U for 72328@debbugs.gnu.org; Fri, 23 Aug 2024 16:21:24 -0400 Original-Received: by mail-wm1-f44.google.com with SMTP id 5b1f17b1804b1-42ab97465c8so18386585e9.1 for <72328@debbugs.gnu.org>; Fri, 23 Aug 2024 13:20:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1724444368; x=1725049168; 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=S5CIaq8tV1zoGOjSEQd3BTJ3IsrHPVhL7N0NIKX+AD4=; b=bEXMTBqsKm9qydMVmnveCZN1B69jnM07731aqt8xP2ntLumgn0DGbOOymM36GVgI3E Qj1Lq8P4583GXSHsWulu/HNq1W31+W+eROV7lrZdR8V3zku9UDSeei49/IDYEeODr1SR sndot1oM+A9+Swicw+oi0sOfhkCzUbKu3x3fBvXrZM76mkCvENYxZf2AcoY6wM3IWz9g WCVYGZstDMNkBLzBmGDyfhhLJ92KeqkEkpUXlfTtoYsWYcGImi52aUXfJwLf7F/0DoNO +bKpbPi0106u8Sf1ObdggyweucA+TLxpD9t5BOq7pGpm0opwyHrK8gvlWxUje+a3o5x+ /raA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724444368; x=1725049168; 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=S5CIaq8tV1zoGOjSEQd3BTJ3IsrHPVhL7N0NIKX+AD4=; b=msI4D6Zzq42Rci5WqJGNpvwopoa5GH/DQSaheT5jUTreYGE96Csy1o2lyaqk6PnNbq tY0J1oAHWAWlh/2frhqEBvOQNnzT+N9htHySdMaIIiIlfyV6Csbq/LnJ8gFOgDOjuJqJ 1kwXfWeJ0nr7vlYNrKkJQ2aSEdefEHMFgb8ZQknNqnNof9v9/5+99IB4g4p2Ttj+G+wQ /iqp24BbXgEVWNTEdSTR1DEydxc55CIaab+7EnEz8FFwXbe1YWLzlNwfsKk8J4s7eb4S Ai1C+eGyVezPmErVgh1tG8AbmI3F6vFgx/bXdoknUtmVMDB8KUV8VsO7S7iuZFnHgJoa Eskw== X-Forwarded-Encrypted: i=1; AJvYcCUoOAXCbBKSimRZtahhikiRL17ZSCu8mNFIdJ8aqwJfQl9FCPdNgnUdlK0XudXq2JCDqZuqDw==@debbugs.gnu.org X-Gm-Message-State: AOJu0YxfJr+qKmu/C7P1hObETfsh4KuWfzeRXtMmeuPvQVRbwdOBjSpQ ZM24PvPKY24fOOXrSiZxyBeCLR+FuZYf44TRyOo0oFT1NyM6OBB03nCXSQ== X-Google-Smtp-Source: AGHT+IGxhcJz5W/4FxzPklFwB/zWYVY8SxTy5GMV+043hBRHROnpaSbGyWsXqn4kiOYO6Z2hvO1GpA== X-Received: by 2002:a05:6000:8d:b0:368:747c:5a04 with SMTP id ffacd0b85a97d-3731185ad48mr1799024f8f.25.1724444367774; Fri, 23 Aug 2024 13:19:27 -0700 (PDT) Original-Received: from thuna-lis3 ([85.104.179.223]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-42abefc604dsm105532445e9.35.2024.08.23.13.19.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 23 Aug 2024 13:19:27 -0700 (PDT) In-Reply-To: <86plpzp6oc.fsf@gnu.org> 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:290610 Archived-At: (Just to address the mail I'm replying to: ) >>> Would be good to hear from Stefan >> The first step is to declare nested backquotes unsupported and add a >> warning when we encounter them. > Where and how would you suggest to do that? If we say that a leading backquote[1] is unsupported in the backquote pattern, then we can just add at to the start of the `(consp qpat)' branch in `pcase--expand-\`' a check like (when (eq (car qpat) '\`) (warn ...)) and that would do.[2] I do not really think that making the nested backquotes unsupported is a good idea - this leaves the only (legal) way to express them in a backquote pattern as `(,'\` ) which is the thing I am trying to fix for commas in the first place. I would rather the original behavior be documented and marked as intended than to have backquotes be illegal entirely. --- Sorry for the radio silence. I have been a tiny bit occupied and haven't been able to spend enough time on this. I still do not really have any examples I can show, but I have been slowly gathering some thoughts on this, and I want to put them out there. >>> Thinking more about it, from the things I can see, I think I'm in favor >>> of this change. In the long run it makes Elisp more consistent. I went in the opposite direction. The more I think about it, and the more I try to write examples this would negatively impact, the less attractive this change starts to look. >>> I don't know how often backquote values are needed to be matched. I >>> guess not terribly often. This is unfortunately a part of the reason this discussion is not really going anywhere (with the other part being me, sorry about that!); this is a *really* niche feature. I expect that the number of people using it does not exceed two digits, if even that. >>> OTOH, this ,'\, circus really can drive none crazy, it's not obvious >>> what one needs to do at all to match a backquote value correctly, so >>> it's also an improvement to enable people to do this in a reachable >>> way, and the code also gets better readable. Yes, that is what I was hoping for with this change, too, but... >>> OTOH, I think the current semantics of pcase ` are easier to explain in >>> a formal way. Dunno if this is an advantage though, since most people >>> don't seem to understand them anyway. ...this is really the issue: The old behavior is very easy to wrap your head around, and its only downside is its inability to express a literal comma match, from which extends the inability to match against /results/ of a backquote form. On the other hand, when you are "out of bounds" of the new behavior - which is whenever you are trying to apply pcase patterns to a technically quoted form within the pcase[3] - you need to create a pattern where the normal backquotes go only as deep as your shallowest comma[4] with the result of the backquotes written using ,'\`. >>> Thuna, do you have any other ideas where your patch would be a >>> significant improvement - practical use cases? I must admit I'm not yet >>> completely sure how the impact of the patch would on using el-search >>> - although I often use it to search backquote expressions. Unfortunately, given the problem above, I would need to discover an improvement that I don't even know of yet to justify advocating for my patch. --- This idea is not yet fleshed out, and it is very complicated one, both conceptually and implementationally, but it would help maintain backwards compatibility while allowing a reasonable representation of literal comma forms in backquote patterns: What if a ,PAT form would match against PAT as though it were a pcase pattern /if any only if/ PAT would not error due to a misplaced call to a comma pattern, and otherwise ,PAT would match against a pcase backquote subpattern (\, PAT)? The way it's stated above is not really illustrative, so let me also explain how it works (as far as everyone will be concerned): Any comma you put before the actual final comma is matched literally. Trying to match against an (unevaluated) object of the form `( ,) would then be done using the pattern `(,(pred symbolp) ,,(pred integerp)) and an (evaluated) object like ``(let ,(list . ) ,,body) would be matched using the pattern ``(let ,(list . ,_) ,body) This comes with its downsides, one of which is that you need to eventually match /some/ pcase pattern to be able to insert a comma. For example, if we had swtiched the object above to ``(let ,(list) ,,body) you would not be able to do ``(let ,(list) ,body) or ``(let ,,(list) ,body) because they would both try to match against `(list)' as though it were a pcase pattern, but there is a solution, which is to just put a quote afterwards: ``(let ,,'(list) ,body) The actual thing that I have not yet managed to work out is whether this could cause a significant amount of false positives, that is, silently matching against a literal comma where an escaping one was intended. I am unable to even construct an example, so it may be that it's not actually possible, but it may also be that I am just not finding it which I can't discount. There is some issue with the way this works "backwards", in that you need to give it more commas the less commas it has (or rather as many commas as it is apart from the nesting of backquotes - this is difficult to even explain!), but I think a simplistic interpretation of it as "give it as many commas as you want to match" would alleviate this somewhat. I have a very rough implementation, but it's not actually working properly and needs a very big overhaul, so I won't (can't) provide it for others to check out how this would work. It should be feasible to do the calculation in your head, so please do that, sorry! --- [1] Currently, pcase doesn't actually check that a comma form is "valid", in that it must be a proper list of length 2, but only checks that the first element in the list is a comma. As a result, something like (pcase '(1) (`((\, (pred integerp) (error))) t)) ;; => t "works" even though it should either be a macroexpansion error or equivalent to the pattern '((\, (pred integerp) (error))). [2] We could be a bit fancier and have a single pcase form only warn once with some bookkeeping, but that would still essentially be something like (when (and (eq (car qpat) '\`) (not pcase--bad-\`-warnedp)) (setq pcase--bad-\`-warnedp t) (warn ...)) [3] Something like the unevaluated `( ,) where is quoted as far as the backquote is concerned. [4] This means that in the example in [3] you have to escape ALL backquotes with ',\`.