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: Mon, 05 Aug 2024 14:52:11 +0300 Message-ID: <86ikwfqj9w.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> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="9535"; 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 Mon Aug 05 13:53:04 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 1sawGt-0002Im-Gm for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 05 Aug 2024 13:53:03 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sawGY-0002fa-0o; Mon, 05 Aug 2024 07:52: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 1sawGW-0002fJ-Gx for bug-gnu-emacs@gnu.org; Mon, 05 Aug 2024 07:52:40 -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 1sawGW-0004ih-6n for bug-gnu-emacs@gnu.org; Mon, 05 Aug 2024 07:52:40 -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=Ugq8NFWs/KUTaMf+W9Byw9JpNm4/247BYznUGVqVZOM=; b=Mf4QD7R8VhXzNh745pS7X0QjkJ9pvkLjrEHpXS6M1FZQJlwkK1z4e8a1AlnxbIZBdmCGw0NNDnR2TuuPT2JOjAj1VnhTaJzVsmVQ9Z01B8BCj8Z0QL8U+Jkxj/lhr5cOo2ERAh8DNqtX++3FGnn4E72bHSOnrJ9oIlMkovWfuLlQFpoAPZEvwVLrixyOKWKY4g3tcEH1ZSwLEfoCKwvHnrq4ESZRH9K9byJCq+sJd5z8/gG03FF6Dm1nBkMQc19ij0trLS1M1oLs1boy1xIdyygh/j/9nDqbndC3u2u8pGS0TelbMI3jIza/1uh63OCHkGdOURGtfjNkwHjJKa1bVw==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1sawGs-0004G1-A7 for bug-gnu-emacs@gnu.org; Mon, 05 Aug 2024 07:53: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: Mon, 05 Aug 2024 11:53: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.172285876616308 (code B ref 72328); Mon, 05 Aug 2024 11:53:02 +0000 Original-Received: (at 72328) by debbugs.gnu.org; 5 Aug 2024 11:52:46 +0000 Original-Received: from localhost ([127.0.0.1]:58172 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sawGb-0004Ey-M8 for submit@debbugs.gnu.org; Mon, 05 Aug 2024 07:52:46 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:59690) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sawGa-0004Ea-24 for 72328@debbugs.gnu.org; Mon, 05 Aug 2024 07:52:44 -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 1sawG7-0004MR-ND; Mon, 05 Aug 2024 07:52:15 -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=Ugq8NFWs/KUTaMf+W9Byw9JpNm4/247BYznUGVqVZOM=; b=JgYNyKBweS8H h5D/Cfe8bdgZpGFJZYJN5zueQeIasQgbA+0jMZCCcZPtmARDH0npdtmjeV2SNCyHavXUf8MBH5sDw F+hbuM2vO2MECx/9udoud/CP90kUhiRgIOyZ9pwR1A+ZfWwra3hNRuPaMb1OBDyJCQTfqGSeMP6Oa qnt18ONgA2K0USavAvxhzGzvqPVVEHgDF6bcgFOcJ9NkbGBLC4H0DVLmbDdwhcEKzDnqAIbHFy5iI MTLOWi0t/EtYWOxoHZqJFT7XsAvEJZxtzOYk07bl9LlSCrgg0ITeubHfchMjoUQVHgA27QqXLqdfr kp1QdIf2xYQavUNsNXtAnA==; In-Reply-To: <87v80gkmg7.fsf@gmail.com> (message from Thuna on Sun, 04 Aug 2024 23:27:52 +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:289789 Archived-At: > From: Thuna > Cc: Eli Zaretskii , monnier@iro.umontreal.ca, > 72328@debbugs.gnu.org > Date: Sun, 04 Aug 2024 23:27:52 +0200 > > >>> Thanks, but I think Stefan meant to say that we would need real-life > >>> use cases to change the current behavior. So if there are no such > >>> cases, it makes the decision less likely. > >> > >> I don't see how Stefan's message could be interpreted that way. > > > > FWIW, I interpreted it that way too. > > My understaning is that the utility of going through use cases for or > against the new behavior is to determine whether it would be an > improvement or not. The absence of any such use cases does not mean > anything in either direction, but simply that this is not a usable tool. The existing implementation has an advantage up front, because it exists and presumably can be used by some Lisp program. We try very hard not to break anyone's code, even if we are not aware of such code, and therefore an incompatible change in behavior can be justified only if there's a very good reason. Thus the request for real-life use cases. AFAIU, those real-life use cases don't have to be from existing packages, they can be from your own practice. You just need to explain why you needed the behavior you are requesting. > Furthermore, just intuitively, why would the absence of users of a > feature be a reason to not improve it? Because the danger of breaking someone's code is not something we ignore lightly. So the improvement must be significant, and the use case must be a practical one, to trump that. > 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. > > From what I understand, coming to decisions as a maintainer is not that > > simple. And Stefan had reasons to choose the current implementation. > > The stated reasoning was that implementational simplicity was valued > over symmetry with backquote. That' too. But the mere existence of the current behavior is also important. > Very well. In that case, here's the original case which prompted me to > look into how pcase's backquote behaves: > > (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.