From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: hokomo Newsgroups: gmane.emacs.bugs Subject: bug#59887: pcase vs. pcase-let: Underscore in backquote-style patterns Date: Tue, 13 Dec 2022 03:26:14 +0100 Message-ID: <87h6y081hs.fsf@airmail.cc> References: <87sfhrqgxw.fsf@airmail.cc> <87v8mhmj26.fsf@web.de> <87pmco8nyc.fsf@airmail.cc> <87edt42jaz.fsf@web.de> <87lenc84df.fsf@airmail.cc> <87a63s2gcm.fsf@web.de> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="7983"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: mu4e 1.8.9; emacs 28.2 Cc: 59887-done@debbugs.gnu.org To: Michael Heerdegen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Dec 13 03:47:19 2022 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 1p4vKA-0001nd-9Q for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 13 Dec 2022 03:47:18 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1p4vJw-0005Cu-SH; Mon, 12 Dec 2022 21:47:04 -0500 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 1p4vJv-0005CX-0B for bug-gnu-emacs@gnu.org; Mon, 12 Dec 2022 21:47:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1p4vJu-00069W-NH for bug-gnu-emacs@gnu.org; Mon, 12 Dec 2022 21:47:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1p4vJu-0003PX-73 for bug-gnu-emacs@gnu.org; Mon, 12 Dec 2022 21:47:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: hokomo Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 13 Dec 2022 02:47:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 59887 X-GNU-PR-Package: emacs Original-Received: via spool by 59887-done@debbugs.gnu.org id=D59887.167089958313102 (code D ref 59887); Tue, 13 Dec 2022 02:47:02 +0000 Original-Received: (at 59887-done) by debbugs.gnu.org; 13 Dec 2022 02:46:23 +0000 Original-Received: from localhost ([127.0.0.1]:57265 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p4vJH-0003PG-0h for submit@debbugs.gnu.org; Mon, 12 Dec 2022 21:46:23 -0500 Original-Received: from [37.120.193.124] (port=36702 helo=mail.cock.li) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p4vJ9-0003P7-VK for 59887-done@debbugs.gnu.org; Mon, 12 Dec 2022 21:46:22 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=airmail.cc; s=mail; t=1670899569; bh=ONQ9LCo46xmbLwVkRij+jjgrFst0+nDrc0kpasJ4u50=; h=References:From:To:Cc:Subject:Date:In-reply-to:From; b=Wn5Kwcz30BG3kOpV6dmW8n0UhBPVakiIQc908BUHBA1ozgrFZBxLowvfqq1TDh2bC 81s6xP1758IdcxAe77TCAFdnOJ1LecH1E5CXJd82hU6k2AfG5KBQg9hQEdzByboDJy 0u37lrhdRJt7QEnBDuQGlV3Misu1a7RZaYBHHqHdZpIZ7jxIkcSg9CNbWH8rYHmart yxDyhVfwsgnQ1j0TwZ6qPCKw1f85BhF93it6fovXBI56P/vYqImIOdv/DYISF+jZu4 0Fs8h9IzU4QAJK9FGjKIjC+KG8IO761Qre0Q4juaipx3GePidUy7qP2RU69Mo2c4+8 OmsmKe/i0kpOw== In-reply-to: <87a63s2gcm.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:250798 Archived-At: > My question is that when we make the text even longer, would=20 > that help > people that don't read carefully (because we don't need to=20 > address > others) at all? I believe it would. Even though I should've been more careful with=20 reading the whole page, one's first instinct (at least mine) when=20 reading a reference manual is to jump directly to the operator in=20 question and expect to find all of the necessary and essential=20 information there, whether it is a detailed explanation or just a=20 hint or short remark mentioning some concepts that were introduced=20 more thoroughly earlier in the manual. As an example, the beginning of the Handling Errors page [1]=20 describes, among other things, the meaning of the `debug' symbol=20 within a condition-case handler's condition list. However, the=20 description of condition-case specifically also includes the short=20 remark "which can include debug to allow the debugger to run=20 before the handler" which is useful to point the reader to the=20 description at the beginning (all it takes is searching for=20 "debug" on the same page after reading the remark). [1]=20 > My second question is if that would have helped you at all,=20 > because your > crucial misunderstanding was about the meaning of `_`. Using=20 > patterns > in `pcase-let' that don't match generally doesn't make much=20 > sense, it's > totally unclear what would happen in this case. That's another=20 > reason > why I don't want to over-emphasize this case. > > Maybe saying that `_` is not special when used as a QPAT would=20 > make > sense, in (info "(elisp) Backquote Patterns"). I mean in this > paragraph: > > | =E2=80=98SYMBOL=E2=80=99 > | =E2=80=98KEYWORD=E2=80=99 > | =E2=80=98NUMBER=E2=80=99 > | =E2=80=98STRING=E2=80=99 > | Matches if the corresponding element of EXPVAL is =E2=80=98equal= =E2=80=99=20 > to the > | specified literal object. > > We could add that `_` is not special (no symbol is special as a=20 > qpat, > actually). Would that give a useful hint? It seems that some=20 > people > seem to expect that `_` is special everywhere in pcase. That is indeed the core of the issue and I definitely think it=20 would be a good idea to have an explicit statement that the=20 underscore symbol is not special as a QPAT. You can sort of infer=20 it from the specification, but given the unspecified behavior of=20 pcase-let in the case of a non-match, making it explicit would be=20 nice. I think I would've ended up poking around pcase-let in any case=20 after being puzzled about its behavior, just out of curiosity.=20 Having a short remark about "structural compatibility" in the=20 documentation of the specific operator would then help me quickly=20 narrow down to what I need. hokomo