From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Update of pcase docs for the elisp manual Date: Tue, 26 Jan 2016 17:38:18 +0200 Message-ID: <83k2mw1hcl.fsf@gnu.org> References: <87d1stznc6.fsf@web.de> <83io2k5yvg.fsf@gnu.org> <83io2j3v4v.fsf@gnu.org> <83egd53acg.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1453822689 18835 80.91.229.3 (26 Jan 2016 15:38:09 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 26 Jan 2016 15:38:09 +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 Jan 26 16:38:08 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aO5h1-0003fy-P8 for ged-emacs-devel@m.gmane.org; Tue, 26 Jan 2016 16:38:07 +0100 Original-Received: from localhost ([::1]:44695 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aO5h1-0007rR-5o for ged-emacs-devel@m.gmane.org; Tue, 26 Jan 2016 10:38:07 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43707) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aO5go-0007rJ-N3 for emacs-devel@gnu.org; Tue, 26 Jan 2016 10:37:55 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aO5gl-0004Dl-Cd for emacs-devel@gnu.org; Tue, 26 Jan 2016 10:37:54 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:38285) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aO5gl-0004Dg-97; Tue, 26 Jan 2016 10:37:51 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1345 helo=HOME-C4E4A596F7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1aO5gk-0007kt-7r; Tue, 26 Jan 2016 10:37:50 -0500 In-reply-to: (message from Stefan Monnier on Mon, 25 Jan 2016 20:40:12 -0500) 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.14 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-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:198853 Archived-At: > From: Stefan Monnier > Cc: emacs-devel@gnu.org > Date: Mon, 25 Jan 2016 20:40:12 -0500 > > >> > Unless, that is, there are important scenarios where using (quote FOO) > >> > in a pattern is required where it isn't a trivial replacement > >> > for 'FOO. > >> A macro (such as pcase) can never distinguish 'A from (quote A) since > >> the reader returns exactly the same result either way. > > Sorry, is that a no? > > It's not just a "no", it's a "no, because it's impossible". > I thought that would be obvious to a seasoned Lisper like you, but > clearly it isn't so we need to say it more explicitly. pcase isn't Lisp, it's a macro that assigns different meanings to some Lisp constructs. > I've appended a suggested patch to try and correct those inaccuracies. Thanks. But I don't understand the rationale for most of the changes. I understand why you suggest to use "backquoted patterns" where I used "QPatterns", and I agree with that. But why all the other changes? E.g., this: > -The @var{pattern} part of a clause can be of one of two types: > -@dfn{QPattern}, a pattern quoted with a backquote; or a > -@dfn{UPattern}, which is not quoted. UPatterns are simpler, so we > -describe them first. If we use "backquoted patterns" here, the rest does have a purpose, and removing it diminishes the ease of reading, I think. The purpose of this was to provide some outlook on the issue that's about to be described. > -The QPatterns are more powerful. They allow matching the value of the > -@var{expression} that is the first argument of @code{pcase} against > -specifications of its @emph{structure}. For example, you can specify > -that the value must be a list of 2 elements whose first element is a > -string and the second element is a number. QPatterns can have one of > -the following forms: > +@node Pcase with backquotes > +@subsubsection Pcase with backquotes > + > +Additionally to the above patterns, one can also use a backquoted > +pattern. This facility is designed with the idea that a backquoted > +pattern should match all values that could be constructed > +by a similarly backquoted expression. For example, you can specify > +that the value must be a list of 2 elements whose first element is the > +string @code{"first"} with a pattern like @code{`("first" ,elem)}. I agree that your example is better, but why the other changes? Why is it important to tell the reader the design idea? I also don't think further dividing this sub-section into sub-sub-sections is a good idea: there are less than 200 lines in it, so it's not too large. The last sub-sub-section you holds just 6 lines, way to few to justify a separate unit, I think. In general, subdividing into nodes breaks the continuity of description, so it's only justified for significant portions or for some obscure aspect (like an extended footnote), or for almost entirely unrelated subjects. None of that happens here, I think. Thanks.