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: Tue, 30 Oct 2018 21:54:29 +0200 Message-ID: <83efc7jjm2.fsf@gnu.org> References: <83tvlcsnee.fsf@gnu.org> <86mur137n8.fsf@gmail.com> <20181029130132.GB4195@ACM> <20181029134722.GC4195@ACM> <87lg6gifnb.fsf@web.de> <87muqwxs7m.fsf@ericabrahamsen.net> <83h8h3jlyd.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1540929148 28919 195.159.176.226 (30 Oct 2018 19:52:28 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 30 Oct 2018 19:52:28 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Oct 30 20:52:24 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 1gHa3s-0007OT-4C for ged-emacs-devel@m.gmane.org; Tue, 30 Oct 2018 20:52:24 +0100 Original-Received: from localhost ([::1]:55229 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gHa5y-0003pP-MG for ged-emacs-devel@m.gmane.org; Tue, 30 Oct 2018 15:54:34 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49251) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gHa5o-0003ni-6F for emacs-devel@gnu.org; Tue, 30 Oct 2018 15:54:25 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gHa5j-0004so-7C for emacs-devel@gnu.org; Tue, 30 Oct 2018 15:54:23 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:46336) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gHa5j-0004sI-1P; Tue, 30 Oct 2018 15:54:19 -0400 Original-Received: from [176.228.60.248] (port=2536 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1gHa5i-0006jR-7N; Tue, 30 Oct 2018 15:54:18 -0400 In-reply-to: (message from Stefan Monnier on Tue, 30 Oct 2018 15:21:52 -0400) 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:230851 Archived-At: > From: Stefan Monnier > Date: Tue, 30 Oct 2018 15:21:52 -0400 > > >> +* Destructuring patterns:: Using pcase patterns to extract subfields. > > We never used "pcase patterns" in the manual before, so I wonder > > whether we should start now. If we want to do that, this should be > > defined before it is used. > > I'm uncomfortable using "pattern" to refer to "pcase pattern" unless the > context makes it clear. I'm not completely sure where best to define > pcase patterns. I think the best place of defining them is where we first describe them, i.e. in the section about pcase itself. > >> +The macros described in this section use @emph{destructuring} > >> +patterns, which are normal Pcase patterns used in a context where we > >> +presume that the object does match the pattern, and we only want > >> +to extract some subfields. > > > > I think we need to define "destructuring" here (or elsewhere in the > > manual, and have a cross-reference there in this section). > > The paragraph you quoted is exactly what I consider the definition of > "destructuring pattern" (I don't see a need to define "destructuring" > separately: the word placed in front of "pattern" is here treated as > a kind of "proper name", just chosen so that it will help some if they > already know the term from elsewhere, such as cl-destructuring-bind). The "destructuring" part needs to make sense, or at least we should strive that it does. It isn't a random word. > > Readers that aren't familiar with that term will not be able to > > understand why this word is used here. We need to start this with > > something like > > > > @dfn{Destructuring} means ... > > I'd rather rename those to "Monnier patterns" and avoid the problem, if > that's what it takes. No, I think "destructuring" is about right. How about this text: @dfn{Destructuring} of an object is an operation that extracts multiple values stored in the object, e.g., the 2nd and the 3rd element of a list or a vector. @dfn{Destructuring binding} is similar to a local binding (@pxref{Local Variables}), but it gives values to multiple elements of a variable by extracting those values from an object of compatible structure. > > It would also help to tell what exactly makes a pattern a > > destructuring one. > > As the paragraph says: it's the context in which it's used. I'm not sure I understand. AFAIU, not every pattern described in "pcase Macro" can be a destructuring one. Right? > >> +All @var{exp}s are evaluated first after which they are matched > >> +against their respective @var{pattern}, introducing new variable > >> +bindings which can then be used inside @var{body}. > > AFAIU, this means only some of the pcase patterns make sense in this > > context. If that is true, I'd suggest ti somehow tell which are (or > > which aren't, if that's easier). > > Not sure what you're thinking of. See above: not every pattern can be a destructuring one, AFAIU. > >> +@defmac pcase-dolist (pattern list) body@dots{} > >> +This construct executes @var{body} once for each element of > >> +@var{list}, in a context where the destructuring pattern > >> +@var{pattern} was matched against the element. > > > > I don't think I understand what "in a context where the pattern was > > matched" means here. Is any aspect of the match except destructuring > > bindings relevant to execution of the body? > > No. But those extra bindings are exactly the context I'm referring to. > In my work, "context" and "environment" are the usual words used to > refer to the map that links identifiers to their corresponding > information (typically, type or value depending on the > ...ahem... context). I find this too abstract in general, so I think it's better to be specific where we can. Thanks.