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:03:54 +0200 Message-ID: <83h8h3jlyd.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> NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1540926113 32310 195.159.176.226 (30 Oct 2018 19:01:53 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 30 Oct 2018 19:01:53 +0000 (UTC) Cc: eric@ericabrahamsen.net, michael_heerdegen@web.de, 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:01:48 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 1gHZGu-0008Iv-KY for ged-emacs-devel@m.gmane.org; Tue, 30 Oct 2018 20:01:48 +0100 Original-Received: from localhost ([::1]:55050 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gHZJ0-0006u9-NG for ged-emacs-devel@m.gmane.org; Tue, 30 Oct 2018 15:03:58 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59207) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gHZIp-0006u3-FF for emacs-devel@gnu.org; Tue, 30 Oct 2018 15:03:48 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gHZIk-0005IA-Lq for emacs-devel@gnu.org; Tue, 30 Oct 2018 15:03:47 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:45206) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gHZIk-0005I6-GP; Tue, 30 Oct 2018 15:03:42 -0400 Original-Received: from [176.228.60.248] (port=3330 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1gHZIk-0003Ze-2s; Tue, 30 Oct 2018 15:03:42 -0400 In-reply-to: (message from Stefan Monnier on Tue, 30 Oct 2018 13:16:33 -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:230848 Archived-At: > From: Stefan Monnier > Date: Tue, 30 Oct 2018 13:16:33 -0400 > Cc: Michael Heerdegen , emacs-devel@gnu.org > > >> I wonder if the manual shouldn't have a section somewhere making > >> explicit the difference between `pcase' -- where a single value is > >> matched against many patterns, and may fail to match altogether, and > >> destructuring is only one of the use-cases -- and the other > > Yes, I'll send a patch for that, > > How 'bout... Thanks. I have a few comments: > +* 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. > +@node Destructuring patterns > +@subsection Destructuring Patterns > +@cindex Destructuring patterns By convention, index entries should start with a lower-case letter. > +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). 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 ... It would also help to tell what exactly makes a pattern a destructuring one. > +@example > + (pcase-let ((`(add ,x ,y) l)) > + (message "Contains %S and %S" x y)) > +@end example > + > +Does the same as the previous example, except that it directly tries You want the text after the example to start like this: @noindent does the same as ... Otherwise, this sentence sounds awkward, and will also be indented. > +@var{bindings} is a list of bindings of the form @code{(@var{pattern} > +@var{exp})} Please use @w{..} around this form, so that it doesn't get broken between two lines. > +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). > +@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? If so, what other aspects are relevant? Thanks.