From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Michael Heerdegen Newsgroups: gmane.emacs.devel Subject: Re: Replace trivial pcase occurrences in the Emacs sources Date: Sat, 03 Nov 2018 23:22:02 +0100 Message-ID: <87zhup2451.fsf@web.de> 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> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1541283660 29043 195.159.176.226 (3 Nov 2018 22:21:00 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 3 Nov 2018 22:21:00 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Nov 03 23:20:56 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 1gJ4Hn-0007Qt-NP for ged-emacs-devel@m.gmane.org; Sat, 03 Nov 2018 23:20:55 +0100 Original-Received: from localhost ([::1]:56952 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gJ4Ju-0005zc-14 for ged-emacs-devel@m.gmane.org; Sat, 03 Nov 2018 18:23:06 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33187) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gJ4Jm-0005zN-4b for emacs-devel@gnu.org; Sat, 03 Nov 2018 18:22:59 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gJ4Jg-00034L-8r for emacs-devel@gnu.org; Sat, 03 Nov 2018 18:22:57 -0400 Original-Received: from mout.web.de ([212.227.17.11]:46021) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gJ4JE-0002lU-FU; Sat, 03 Nov 2018 18:22:27 -0400 Original-Received: from drachen.dragon ([94.218.210.177]) by smtp.web.de (mrweb103 [213.165.67.124]) with ESMTPSA (Nemesis) id 0LiUKG-1fgh9D3mWa-00cfj7; Sat, 03 Nov 2018 23:22:04 +0100 Original-Received: from drachen.dragon ([94.218.210.177]) by smtp.web.de (mrweb103 [213.165.67.124]) with ESMTPSA (Nemesis) id 0LiUKG-1fgh9D3mWa-00cfj7; Sat, 03 Nov 2018 23:22:04 +0100 In-Reply-To: <83pnvmdp1i.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 03 Nov 2018 19:55:05 +0200") X-Provags-ID: V03:K1:pS6vMZctKsUSio7zV6vVpHvihlM9v/VKRstXWkd7JL1wCxC5XSj RaYaStPKgvH7mWqrwxXKetgH/J2eJVMGdqmVwoH+uZhTxRFoSeBWFvGA8rnOYV/xpLy7MKj VHnKQbpHhXIYNcnc4PMhWowqCKRGox5/0GpUov8zD3htLEmSZQvnnGnthEGYB0foPjEGmWa 1btf9Xvvrltoq4+znsNXA== X-UI-Out-Filterresults: notjunk:1;V01:K0:XyWxmJ9JXKM=:3jKS3MwsVTWVTLol8ZSOBC m+1K353HOpDhKuqMcOSv3HM2TOM5Q9zl3aCNitlIt/m5TuTwgVEQBj/X/xSOXoPqkxhi9Co+M Ul/1D/eI/kwgbIyxITItflQcbi7edk4X0ehx2i18PCh9FzCtCxImK0KwBRWUFGy9WyViLrrXv kGGlXzZ/7qkBMSspJyRaEEwd8JzDw8yO6GYV9ODg3AyfS8WFZ00bECXyj34CVlNzOegExUACh gTuKzRW/fGosTLXeAN/jb52V7Clmzg8y2IWuMA+Ne6ZURpIpZnXFUrXiicoJoq/KI47r0aiSe bTbuxgREuvceqNMkz0j5YYalmLSRliW0B+A8I/w4mh4uVz1v7O6kMpo+/lmxNtlVrpbm5jC94 aUbM16n32ysmdiEIsERKTspdD2h7zTZt0pOeCPK4b7Ko0e7FUka0wbabIhFqNs/wz9Aqb3MXX Bk2Lj0VSefLZre5Q9Fh1d0wYX+ZpwSGuCAkT8nl8dns90C8IDtStVIG6MzzewE7PgVKbU0d/R 9oJPZA3ydXB1a6uYTfKEiwycKYiZy8AFEGvAPSkJhvQdTpMsmetr2pgSmGQ47EHBWhOuhhLEE ffS/bT/AU79HmeObsxgZtyddisF5B+pVM4nApeOyPKSST/4Ej+02b+N9G5ta/myWf5h+FNYck OHLWiq6fHHlI9zZVUrF1WiJ6L3kKh377/LxtxRMWHZt9xdw+VTAJJH73AbhTtpPXAf60y31Lj uNcWx7aLQarQomwNNmGc3ZJcyPbXDqVfi3mBYp27OJSskEObnC9UOleKO/kp9QN8gPp1BgSr X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 212.227.17.11 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:230998 Archived-At: Eli Zaretskii writes: > > We called these UPATS in the past btw. That should have been QPATs, sorry. > Sorry, I'm still in the dark here. 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 find the wording used in (info "(elisp) Backquote Patterns") confusing, especially the first sentence "This subsection describes =E2=80=9Cbackquote-style patterns=E2=80=9D, 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. > > > > (2) We already have a lot other patterns for destructuring > > > > (eieio, seq, map, cl-struct), and we probably will get even more > > > > in the future. > > > > > > OK, but why is that a reason not to use what I wrote? Note that it > > > talks about "destructuring binding", not just about destructuring. > >=20 > > Well, for binding there is only one pattern, SYMBOL. But you also > > write > >=20 > > | since they express a specification of the structure of objects that > > | will match. > >=20 > > so this seems to speak about destructuring and not about binding. > > Destructuring binding requires destructuring, that's all. "Destructuring binding" - pcase has nothing like that. 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. 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 `. > Again, I don't understand the nature of your objections to the text. > > > | The pcase patterns that are useful for destructuring bindings are > > | generally those described in @ref{Backquote Patterns} > >=20 > > 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 ;-) > I submit that any other example, except the ones that follow my > description, will have the same property: they can be rewritten > cleaner, and in many cases also shorter, than using pcase-let etc. But that's personal preference. I found at least one example of such a `pcase-let' that doesn't use destructuring in the Emacs sources. It isn't wrong just because you would personally write it in a different way, and it should be understandable after reading the docs. All occurrences should be understandable after reading the docs, not only those that are main use cases or cases that the inventor had in mind when the thing was created. > > And docstrings shouldn't tell restrictions that don't exist just > > because you would prefer `cond' in such cases anyway. > > So you seem to object to the doc string describing only part of the > possible uses? If so, this argument was already voiced in the > discussion, and I already said that I think it's a mistake to make our > documentation more vague and therefore more confusing, for the benefit > of being 100% accurate. I don't suggest to make it vague. In my option, what you did in your change makes it more vague, actually. What we write in the docs should be correct, at least. > IOW, it is quite clear that, knowing the way a macro is implemented, > one can tweak the macro into doing stuff it never was designed to do. These are still valid use cases. > But we introduced pcase-let for a reason, and AFAIU that reason is to > allow destructuring binding. It can also do other things, but nothing > important will be lost by making the documentation general enough, and > thus vague/abstract enough, to cover those other use cases. I don't understand what this means in concrete. > > > > Also the docstrings give the impression that these are limited to > > > > destructuring, which is not true. > > > > > > Can you tell where did you get that impression? The doc strings talk > > > about destructuring bindings, when BINDINGS have the form specified, > > > and I believe that is true. > >=20 > > You say > >=20 > > | Perform desctructuring binding of variables according to > > | @var{bindings}, and then evaluate @var{body}. > >=20 > > Any pcase PATTERN can be used in BINDINGS, whether it performs > > destructuring or not, the only assumption is that it should match. > > But these macros were invented to support destructuring, don't you > agree? To 100%. > 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 didn't restrict to what data and from where. Destructuring comes to my mind when I read that, but "extracting data" doesn't explicitly limit it to that case. I wouldn't have chosen that wording, however. It was not the original docstring, btw, but one Stefan had rewritten after he had been urged to by people (like you) who were not happy with the original docstring. The original docstring was clearer in that regard, indeed. > I think we should describe the intended usage of these macros first > and foremost. If the other uses can be described without losing > clarity, fine; but that's not the case here, as the long discussions > seem to show -- people were unhappy with the original abstract and > general descriptions because they didn't tell them enough about the > main use case. I'm not against telling the main use cases. But a thing isn't described completely or even in a good way only by telling the main use cases. > > You can say that pcase-let is mostly useful for destructuring the > > bound values, but as a summary of what `pcase-let' and the like is > > about it's misleading. It's misleading because I then wonder where > > the restriction to destructuring comes from, and what's different to > > just matching the patterns against the values as in `pcase'. > > I disagree that it's misleading. If you care so much about the > restrictions, or lack thereof, you are welcome to study the code. But > the doc string should explain how to use the macro to the rest of us. Say the "rest of us" is 50% of the people. The other 50% don't matter? The docs get more confusing for them. What would you say if I would change the docstring of `cond' to say it's limited to the cases where I would use it, just because I, and lots of other people ("the rest of us") would prefer something more suited in our eyes in these cases, like pcase? Also, not only people write pcase/pcase-let expressions, but also code can do that. The documentation should make clear what is allowed and what not also for that case. After saying that you can write how the main use cases look like. FWIW, I always thought that the docstrings tell how something works and what it does, and the manual is for learning and telling use cases. 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. Michael.