From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Andy Moreton Newsgroups: gmane.emacs.devel Subject: Re: Replace trivial pcase occurrences in the Emacs sources Date: Wed, 31 Oct 2018 00:21:27 +0000 Message-ID: <8636snx8xk.fsf@gmail.com> References: <86mur137n8.fsf@gmail.com> <20181029130132.GB4195@ACM> <20181029134722.GC4195@ACM> <20181030180941.GA5705@ACM> <20181030190026.GD5705@ACM> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1540945223 29907 195.159.176.226 (31 Oct 2018 00:20:23 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 31 Oct 2018 00:20:23 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (windows-nt) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Oct 31 01:20:19 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 1gHeF8-0007et-Ra for ged-emacs-devel@m.gmane.org; Wed, 31 Oct 2018 01:20:18 +0100 Original-Received: from localhost ([::1]:56188 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gHeHF-0002eo-9E for ged-emacs-devel@m.gmane.org; Tue, 30 Oct 2018 20:22:29 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40525) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gHeGb-0002eX-Rr for emacs-devel@gnu.org; Tue, 30 Oct 2018 20:21:50 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gHeGY-0006OY-Kf for emacs-devel@gnu.org; Tue, 30 Oct 2018 20:21:49 -0400 Original-Received: from [195.159.176.226] (port=34770 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gHeGY-0006LE-BF for emacs-devel@gnu.org; Tue, 30 Oct 2018 20:21:46 -0400 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1gHeEH-0006hP-Jl for emacs-devel@gnu.org; Wed, 31 Oct 2018 01:19:25 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 60 Original-X-Complaints-To: usenet@blaine.gmane.org Cancel-Lock: sha1:NarbeaWHzA5bJSpXmGKAyycvHWE= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 195.159.176.226 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:230864 Archived-At: On Tue 30 Oct 2018, Alan Mackenzie wrote: > Hello, Stefan. > > On Tue, Oct 30, 2018 at 14:17:10 -0400, Stefan Monnier wrote: >> > Not everybody is familiar with dolist by any means. Is dolist's doc >> > string of sufficiently high quality to act as this basis? > >> If dolist's docstring is not good enough, then I don't think it's >> pcase-dolist's job to fix it. > > I think everybody would agree with this point. > >> >> We do have to keep the reference to `pcase` because we don't want to >> >> repeat the definition of what a pcase pattern can look like. > >> > Yes, I think that's right. > >> > Things I believe MUST appear explicitly in the doc string for >> > pcase-dolist: >> > 1. It is a loop over the elements of LIST, which must be a list. >> > 2. It attempts to match the current list element with the supplied >> > PATTERN, which must be a valid pcase style pattern. >> > 3. The BODY forms are evaluated for each element of the list. >> > 4. The purpose of the matching is to create bindings for symbols, and >> > these bindings are in force when the BODY forms are evaluated. >> > 5. When a pattern match fails, ..... (This needs to be stated). > >> This is highly redundant w.r.t pcase-let and dolist. > > Maybe, but so what? > > Doc strings should be as far as is reasonable self contained. Have a > look at the doc strings for let and let*. They have a great deal in > common, but each is self contained. Exactly. For the pcase macros, the docstrings need to describe what the arguments are, and what the macro actually does. A reference to `pcase' itself to describe the patterns is fine. The last thing in the docstring should be a reference to the similarly named non-pcase construct with similar behaviour (which is the least important part). >> Fine for the manual, but not for docstrings. > > You seem to be arguing that doc strings needn't say what > de{fun,macro,var}s do and are, as long as the meaning can be acquired > through the traversal of a directed acyclic graph of linked doc strings. > Maybe you find this a good way of acquiring information, but I certainly > don't. I just get angry and frustrated, and I'm sure I'm not the only > one. Me too. Docstrings are to educate and inform users, and lead them to discover new functionality (and hopefully read the manual for more detailed discussion). A little redundancy of presentation is actually a good thing if it aids the understanding of non-experts who are trying to learn. AndyM