From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Replace trivial pcase occurrences in the Emacs sources Date: Sun, 04 Nov 2018 16:16:19 +0200 Message-ID: <83ftwhdj2k.fsf@gnu.org> References: <83r2g8klf9.fsf@gnu.org> <83wopzk3sw.fsf@gnu.org> <83r2g7jrot.fsf@gnu.org> <83k1lzjq0r.fsf@gnu.org> <83in1jjmy4.fsf@gnu.org> <20181031120821.GA20575@ACM> <831s86jey9.fsf@gnu.org> <83wopue1xl.fsf@gnu.org> <87o9b62mij.fsf@web.de> <83sh0idt6m.fsf@gnu.org> <87efc22igk.fsf@web.de> <83pnvmdp1i.fsf@gnu.org> <87zhup2451.fsf@web.de> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1541340891 22042 195.159.176.226 (4 Nov 2018 14:14:51 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 4 Nov 2018 14:14:51 +0000 (UTC) Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Michael Heerdegen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Nov 04 15:14:47 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gJJAs-0005cn-HU for ged-emacs-devel@m.gmane.org; Sun, 04 Nov 2018 15:14:46 +0100 Original-Received: from localhost ([::1]:59172 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gJJCy-0004pf-Ua for ged-emacs-devel@m.gmane.org; Sun, 04 Nov 2018 09:16:56 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45408) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gJJCm-0004pM-Lz for emacs-devel@gnu.org; Sun, 04 Nov 2018 09:16:45 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gJJCi-00068a-Mv for emacs-devel@gnu.org; Sun, 04 Nov 2018 09:16:44 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:57508) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gJJCa-0005yr-Nv; Sun, 04 Nov 2018 09:16:36 -0500 Original-Received: from [176.228.60.248] (port=4733 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1gJJCT-0005vO-MV; Sun, 04 Nov 2018 09:16:32 -0500 In-reply-to: <87zhup2451.fsf@web.de> (message from Michael Heerdegen on Sat, 03 Nov 2018 23:22:02 +0100) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:231006 Archived-At: > From: Michael Heerdegen > Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org > Date: Sat, 03 Nov 2018 23:22:02 +0100 > > > The node I pointed to describes > > "backquote-style patterns", and explains that these "ease structural > > matching". The same patterns are useful for destructuring binding, > > precisely because destructuring binding needs a structural match. > > That is all that I'm trying to convey. Making that point will help > > the reader to understand what subset of pcase patterns will be most > > useful for destructuring. > > So, I should read it as "the set of patterns that are of the form > `SOMETHING"? I had read it as the set of what we call "QPATs". So we > have probably talked about different things. I refer to the patterns described in that section. They are all `SOMETHING, but not just any SOMETHING. Does that answer your question? (Please don't talk about QPATs, that term no longer exists in the manual, so using it is just making this discussion more confusing than it already is.) > I find the wording used in (info "(elisp) Backquote Patterns") > confusing, especially the first sentence "This subsection describes > “backquote-style patterns”, a set of builtin patterns that eases > structural matching." which seems to introduce a whole set of builtin > patterns though it talks only about one macro, `. > > You only refer to that in your change, using the same wording, so what > you changed is consistent with what we have, although I don't like it > that much. The current description of pcase uses took a lot of time and effort to get to the current shape, so I'm going to trust those who labored on it that they found the best balance between clarity and accuracy. In any case, that's a separate issue, let's please not mix them. I didn't change anything in that section, only referred to it. > > Destructuring binding requires destructuring, that's all. > > "Destructuring binding" - pcase has nothing like that. The section in question is not about pcase, it's about pcase-let, pcase-let*, and pcase-dolist. > We have a > pattern type for binding, SYMBOL, and diverse for performing > destructuring, ``' being the main and most general one. You can combine > these, but both are different things. The macros described in the section we are talking about provide a kind of binding. I needed to describe how to use the combination of the above, so I called that "destructuring binding", both to follow terminology accepted in other languages and to provide a concise description of this combination that doesn't require too many words. Since you seem to agree that there is destructuring and there is binding, I don't understand the nature of your objections to the term "destructuring binding", as defined in this section. Are you saying that this description: [...] similar to a local binding (@pxref{Local Variables}), but gives values to multiple elements of a variable by extracting those values from an object of compatible structure. is incorrect, or that pcase patterns don't allow them, or that pcase-let etc. is not about using such bindings in the BODY? > We talk about this paragraph: > > | +The pcase patterns that are useful for destructuring bindings are > | +generally those described in @ref{Backquote Patterns}, since they > | +express a specification of the structure of objects that will match. > > I would already be happy if you would leave out the word "bindings". > Establishing bindings is not the only use of `. The text doesn't say that the only use of ` is for establishing bindings. It says that destructuring bindings can be done by using backquote-style patterns. That's not the same, as you surely realize. If A can be done by using B, it doesn't imply that B's only use is to do A. The text you quote says the former and never says anything to imply the latter. So I'm really surprised that you interpret it that way. > > > | The pcase patterns that are useful for destructuring bindings are > > > | generally those described in @ref{Backquote Patterns} > > > > > > makes it sounds if ` is the only method to get destructuring bindings > > > with pcase. > > > > No, it says those are _useful_ for destructuring bindings, that's all. > > I'm sure you realize that saying A doesn't say that there's nothing > > but A. > > Sorry, I'm not an native English speaker. But "are generally those" > sounds quite, well, generalizing to me ;-) Would you be happier if the text said "typically" instead of "generally"? Because that's what it means. > > Stefan's original text talked about extracting values (or subfields), > > so it was clear to me that Stefan, too, alluded to destructuring. > > It talked about "extracting data". It talked about extracting subfields of objects. Isn't that destructuring? > It's also a difference between "... is typically used for" (which I > would find ok) and "... does this and that" and it's not accurate. Could you please tell what concrete changes in the doc strings of pcase-let etc. would make you happier? I feel that we are trapped in abstract discussions with no clear way out, and I think I'm at least slightly confused what is it that you don't like about the current docs. Concrete proposals for changes might go a long way towards dispersing the fog. Thanks.