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: Predicate for true lists Date: Fri, 06 Jul 2018 08:57:52 +0300 Message-ID: <83h8lcnbxb.fsf@gnu.org> References: <87fu3vdjjk.fsf@tcd.ie> <87bmcqhhsf.fsf@tcd.ie> <87in6xgtpb.fsf@tcd.ie> <2af892df-26cb-60b2-4fd8-067fcb3d32e9@cs.ucla.edu> <87r2kh9uwx.fsf@tcd.ie> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1530856592 29225 195.159.176.226 (6 Jul 2018 05:56:32 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 6 Jul 2018 05:56:32 +0000 (UTC) Cc: eggert@cs.ucla.edu, emacs-devel@gnu.org To: "Basil L. Contovounesios" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jul 06 07:56:28 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 1fbJjF-0007Pk-8u for ged-emacs-devel@m.gmane.org; Fri, 06 Jul 2018 07:56:25 +0200 Original-Received: from localhost ([::1]:55908 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fbJlK-0002Wc-HI for ged-emacs-devel@m.gmane.org; Fri, 06 Jul 2018 01:58:34 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35492) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fbJkh-0002WL-C6 for emacs-devel@gnu.org; Fri, 06 Jul 2018 01:57:56 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fbJke-0002yV-7g for emacs-devel@gnu.org; Fri, 06 Jul 2018 01:57:55 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:42587) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fbJke-0002yD-45; Fri, 06 Jul 2018 01:57:52 -0400 Original-Received: from [176.228.60.248] (port=3025 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1fbJkd-0003Bd-HQ; Fri, 06 Jul 2018 01:57:51 -0400 In-reply-to: <87r2kh9uwx.fsf@tcd.ie> (contovob@tcd.ie) 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:226983 Archived-At: > From: "Basil L. Contovounesios" > Date: Fri, 06 Jul 2018 01:31:26 +0300 > Cc: emacs-devel@gnu.org > > I attach three patches (and a benchmark). The first introduces the > function proper-list-length as per your suggestion in > https://lists.gnu.org/archive/html/emacs-devel/2018-06/msg00138.html > (please check whether I have properly attributed you, as I am unfamiliar > with the preferred way of doing this). > > The second changes the Elisp manual to refer to "proper lists" instead > of "true lists". > > The third moves the definition of zerop in lisp/subr.el from under the > 'List functions' heading to under the 'Basic Lisp functions' heading. > > Finally, here are the updated (byte-compiled) benchmark results: > > ‘proper-list-length’ > proper (0.004452047000000001 0 0.0) > dotted (0.005584044999999999 0 0.0) > circular (0.006193915 0 0.0) > ‘format-proper-list-p’ > proper (0.06397756299999999 0 0.0) > dotted (0.063610087 0 0.0) > circular (0.09455345899999999 0 0.0) > ‘ert--proper-list-p’ > proper (0.29080201899999997 0 0.0) > dotted (0.290801063 0 0.0) > circular (0.433813842 0 0.0) > > WDYT? Thanks, I have a few comments below. > >From f42cb45f449dbb6c3d806398a128bc5914fdebab Mon Sep 17 00:00:00 2001 > From: "Basil L. Contovounesios" > Date: Fri, 6 Jul 2018 00:41:11 +0300 > Subject: [PATCH 1/3] Add convenience function proper-list-length > > * lisp/subr.el (proper-list-length): New function. > Suggested by Paul Eggert in > https://lists.gnu.org/archive/html/emacs-devel/2018-06/msg00138.html. > * doc/lispref/lists.texi (List Elements): > * etc/NEWS: Mention it. The "it" part here is ambiguous, because it's too far from the last place where the function's name was mentioned. Please state the name of the function for better readability. > * lisp/emacs-lisp/byte-opt.el (byte-optimize-if): > * lisp/emacs-lisp/cl-macs.el (cl--make-usage-args): > * lisp/org/ob-core.el (org-babel-insert-result): Use it. Likewise. > * lisp/emacs-lisp/ert.el (ert--proper-list-p): Remove. > (ert--explain-equal-rec): Use proper-list-length instead. > * lisp/format.el (format-proper-list-p): Remove. Maybe consider mentioning that these are removed "because SUCH-AND-SUCH replaces them in file FOO." > +@defun proper-list-length object > +This function returns the length of @var{object} if it is a proper > +list, @code{nil} otherwise. In addition to satisfying @code{listp}, a > +proper list is neither circular nor dotted. Proper list is defined elsewhere in the manual, so please add here a cross-reference to that spot (I'd suggest doing that with @pxref in parentheses at the end of the first sentence). > +** New function 'proper-list-length'. > +Given a proper list as argument, this function returns its length; > +otherwise, it returns nil. This function can thus be used as a > +predicate for proper lists. Do we really want this usage of the function as a predicate? I find this slightly unnatural, and also not future-proof enough, because you rely on the checks 'length' does internally. If the internals of 'length' change one day, this predicate usage will collapse like a house of cards. Would it make more sense to have a separate predicate? > +(defun proper-list-length (object) > + "Return OBJECT's length if it is a proper list, nil otherwise. > +A proper list is neither circular nor dotted (i.e., its last cdr > +is nil)." But if we do want to use this as a predicate, then the doc string should say so. > * doc/lispref/lists.texi (Cons Cells, Building Lists): > * doc/lispref/sequences.texi (Vector Functions): Do it. Please put the full description in the log entry. "Do it" refers to what the header says, I presume, but I at least am used to ignoring the headers and reading the entries, because they are generally more informative (due to space constraints on the header). > +@cindex proper list > @cindex true list > Also by convention, the @sc{cdr} of the last cons cell in a list is > @code{nil}. We call such a @code{nil}-terminated structure a > -@dfn{true list}. In Emacs Lisp, the symbol @code{nil} is both a > +@dfn{proper list}. In Emacs Lisp, the symbol @code{nil} is both a We still have "true list" in the index (and rightly so), so I think the new text should say, perhaps in parens or in a footnote, that such lists are also known as "true lists". Imagine a reader who follows the "true list" index entry and gets placed on this text -- they will be confused to not see "true list" mentioned anywhere. Besides, that term is in wide usage elsewhere. Thanks again for working on this.