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: Tue, 06 Aug 2024 15:09:57 +0200 Message-ID: <871q31ztju.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> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="13399"; mail-complaints-to="usenet@ciao.gmane.io" Cc: michael_heerdegen@web.de, monnier@iro.umontreal.ca, 72328@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Aug 06 15:12:08 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 1sbJyx-0003F5-O6 for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 06 Aug 2024 15:12:07 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sbJyY-0003g1-74; Tue, 06 Aug 2024 09:11: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 1sbJyU-0003Vt-Mb for bug-gnu-emacs@gnu.org; Tue, 06 Aug 2024 09:11: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 1sbJyU-0003IA-Av for bug-gnu-emacs@gnu.org; Tue, 06 Aug 2024 09:11:38 -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=EOS7EOryl29esSYh/PyRbsKCEMW60p+9HKQ1G7CAh/E=; b=oo/dOtPGYNUNId+Rd6E556gG4ocQmy5W9PX3Fugrg2yT7g7CYHoKpXu7wkYI51BG+a+X2AWzTGRHoqLo/avQkYvYw9Dj2acmlkVph4xnMCUe0TLx64wkiA6EkZXYBuo9XN9hOLprqqbZxCX3CASKPsqYtMZSWh1pP4UoDEdGgGbQKyf+aooC0GsbGNKYiER/CyDBfS/xaqGGhhBxAJ7+E+JuBOv/IRZO8pHj9+LrKKQrWi4TadD9jLMPX2/PgFqh9LbqNI6UFD9AJcVVLj5B11kyextaCKgoaBg1gOjsiqTIcYKYnRDCZcqjFuOBMFQCBhfStE/t/2ZcTZq6P2KC2g==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1sbJyr-0004gy-Nu for bug-gnu-emacs@gnu.org; Tue, 06 Aug 2024 09:12:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Thuna Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 06 Aug 2024 13:12:01 +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.172294989417988 (code B ref 72328); Tue, 06 Aug 2024 13:12:01 +0000 Original-Received: (at 72328) by debbugs.gnu.org; 6 Aug 2024 13:11:34 +0000 Original-Received: from localhost ([127.0.0.1]:60439 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sbJyP-0004g2-Ts for submit@debbugs.gnu.org; Tue, 06 Aug 2024 09:11:34 -0400 Original-Received: from mail-lj1-f171.google.com ([209.85.208.171]:50362) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sbJyN-0004fh-7u for 72328@debbugs.gnu.org; Tue, 06 Aug 2024 09:11:32 -0400 Original-Received: by mail-lj1-f171.google.com with SMTP id 38308e7fff4ca-2eeb1ba0468so9688531fa.0 for <72328@debbugs.gnu.org>; Tue, 06 Aug 2024 06:11:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1722949801; x=1723554601; 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=EOS7EOryl29esSYh/PyRbsKCEMW60p+9HKQ1G7CAh/E=; b=moDtCyfVxacGQsrBuzS4f6RuYO6pqRgMYylmSs+/kq6fIhTvQCVkOWvlkFkxrpRsTr 3lFMXm3mYXT7I3PDXRgFr1tDywfp32Jap1cVJEQkTeKF2y/wV/BAZZV5kzewRuq8ZWw/ OtrjbiiITMRHaSnHpvA0g3bqjxg4z7uWHeFfit47xVM0q2ROTxF28qj34rcU7vcBDJN5 JWXYzqTbWbYPXT2SPQoqZrrPuaXO4M5P1Zm20KGS26CWoS/wP2K/CY6WSmo4cndO1Owv WbhbhJwgp1Xn0zhsHLsX4ivNrVZ4olRejVuI9vVjtv4NutaR87KAmmXdO6AmU9fxNHH5 WsUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1722949801; x=1723554601; 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=EOS7EOryl29esSYh/PyRbsKCEMW60p+9HKQ1G7CAh/E=; b=rdEFAPAuYH5vAFvaXOE+/iZdsLTnD7poWJiBXDJrutDVcA19to2gSrAxQVDSQnjLqD BGTg2J2keBg0yUtHhjFdtqw8DAM9d/HnTNCIYWkruFHGWVw7APfRJESWjW1kg4fJvGvb wBLTljnaGESD7dkdV5WogLrlEv2eV2fCeCsqN9Pgm0fz/UWf+vUmqFQexX0v87E7L3gl QSSpDyQMihvmtf6/km4mujZCQ2DuevNHRRsnanTeFOf1QkKhOG89G8cp+P0WFivM11J2 +oAeRzRBzhX589sdHURuaak3BduXXEs/8CU8GX5PV5PLB+UnpP1TP6eXFZXVyMI9wYWn 9yzw== X-Forwarded-Encrypted: i=1; AJvYcCU5bJ8MYPPdxUk3jKkJaTNqrZc1ckubuNK7dkakApz5HiT/f9pfvZUx+g7QDMJ6BdgIwbWW1cTqhtX3Rs0Y9GFWHTT5mh0= X-Gm-Message-State: AOJu0YznTsyhIJOjrdPE2xO5vTKHdsnySNHx/50H4MHzJTUsJnbC7lp1 aOSZUOCW6L5e1f0rfnQUCNqsIpy61gFzVKGGaKKVx9vKme21HRNgq2Rpfd9P X-Google-Smtp-Source: AGHT+IGz0Tbtn/gFbcMkRxHGaNXOYN/qwiqVqDKLqH46RQkowdsYX7xQ9B2Z769IAq+iXxU2OHRyYA== X-Received: by 2002:a2e:b170:0:b0:2ef:1bd5:bac3 with SMTP id 38308e7fff4ca-2f15ab419camr106154721fa.41.1722949800146; Tue, 06 Aug 2024 06:10:00 -0700 (PDT) Original-Received: from thuna-lis3 ([85.106.105.81]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-428fe2492fesm18883065e9.0.2024.08.06.06.09.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 06 Aug 2024 06:09:59 -0700 (PDT) In-Reply-To: <86o765q4yo.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:289827 Archived-At: >> >> Note that I do not believe that there are no people who would be >> >> effected by this, positively or negatively. >> > >> > We've learned from bitter experience that such arguments are usually >> > false. IOW, we don't really know enough to make such assertions. >> >> I think there is a misunderstanding. I am not saying that there isn't >> anyone who would be effected by this, it is the opposite. I understand >> that this will effect people, and I agree that at minimum there needs to >> be a decent period where the current behavior is maintained but marked >> as obsolete. > > How do you envision making such a behavior change in a way that will > leave the current behavior still maintained (and obsolete)? In the patch I provided the check for `(<= depth 0)' can be moved out of the conditions and into the branches as `(unless (<= depth 0) (macroexp-warn-and-return ...))' and it should work identical to how it does now. We can also semi-support the new behavior at the same time by making it so that if there are nested commas in the pattern it uses the new behavior. This should not cause any backwards-incompatibility because a nested comma in a pcase is currently just an error. If this is something that would be of interest I can look into providing a patch for it. >> An indefinite feature-freeze is where I have a problem. > > Disagreeing with a specific change is not tantamount to an indefinite > feature-freeze. It is quite possible that someone will come up with a > different idea of a change, which we will be able to reconcile easier > with the previous behavior. As long as the goal of such a change is to establish symmetry with quasiquote, you can not reconcile the fact that the current behavior and the expected behavior on the pattern ``,foo are incompatible. >> >> (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." >> >> (pcase exp >> >> ((or 'nil ''nil '#'nil '`nil ``,,(pred macroexp-null)) >> >> t))) >> >> >> >> which without this change would read as: >> >> >> >> (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." >> >> (pcase exp >> >> ((or 'nil ''nil '#'nil '`nil >> >> `(,'\` (,'\, ,(pred macroexp-null)))) >> >> t))) >> > >> > Thanks, now you just need to explain why you needed this code and what >> > did its caller do to require this. >> >> I do not understand what you are asking for. Whether `macroexp-null' >> should exist or not, what it is trying to do should be fairly clear, so >> should the way in which it benefits from the changed behavior. > > I asked to explain _why_ you need this. Risking to say the obvious, a > program exists to do some job, and a function like the above is > therefore part of some larger job. We are asking you to describe the > higher-level context, which we could then use to try to decide whether > the need is important enough to justify the backward-incompatible > change. And I am saying that that broader context of this example is not meaningful in any way; I provided it solely because of the ask for a real-life use-case. I would appreciate not being put in a situation where I must defend multiple patches (one not even proposed) at once. Whether this new behavior is or will be used in emacs does not matter. I am not proposing this change to make further patches more convenient, but because I believe that it is the correct way for pcase to behave. >> I also cannot provide any justification for this patch above and beyond >> what I have already mentioned in my initial message: This patch >> establishes a symmetry between pcase's backquote pattern and quasiquote, >> which allows trivially matching against the result of a quasiquote form. > > We would like to hear reasons for wanting this. At the risk of repeating myself: (pcase ``,foo (``,foo foo)) should not return (\, foo). The current behavior is unintuitive and makes patterns actually matching against quasiquote forms essentially write-only. >> I would appreciate it if you would state your opinion on this patch, >> putting aside concerns of backwards compatibility for a moment. I am >> working under the assumption that this is an improvement and is >> desirable, yet I have not yet heard from you or Stefan as to whether you >> see it that way or not. > I believe Stefan did say that. Me, my only stake here is the concern > of backwards compatibility, which is why I'm talking only about that. 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.