From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.devel Subject: RE: seq-some-p and nil Date: Mon, 7 Sep 2015 10:08:22 -0700 (PDT) Message-ID: <357b0d47-2ad9-4711-a706-3beea4af6166@default> References: <1441295429.4215.0@smtp.gmail.com> <87si6vl21r.fsf@petton.fr> <878u8k2vnp.fsf@udel.edu> <878u8i69ok.fsf@petton.fr> <674102d7-0e97-478a-af05-ca6d82c17c28@default> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1441645748 18044 80.91.229.3 (7 Sep 2015 17:09:08 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 7 Sep 2015 17:09:08 +0000 (UTC) Cc: Mark Oteiza , Nicolas Petton , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Sep 07 19:08:54 2015 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 1ZYzuX-0001Ka-Hc for ged-emacs-devel@m.gmane.org; Mon, 07 Sep 2015 19:08:53 +0200 Original-Received: from localhost ([::1]:57924 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZYzuX-000139-LR for ged-emacs-devel@m.gmane.org; Mon, 07 Sep 2015 13:08:53 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39938) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZYzuJ-000108-H7 for emacs-devel@gnu.org; Mon, 07 Sep 2015 13:08:40 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZYzuE-0006bB-F0 for emacs-devel@gnu.org; Mon, 07 Sep 2015 13:08:39 -0400 Original-Received: from userp1040.oracle.com ([156.151.31.81]:41258) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZYzuE-0006b3-8e for emacs-devel@gnu.org; Mon, 07 Sep 2015 13:08:34 -0400 Original-Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t87H8VOY003717 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 7 Sep 2015 17:08:33 GMT Original-Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0022.oracle.com (8.13.8/8.13.8) with ESMTP id t87H8VGx014410 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 7 Sep 2015 17:08:31 GMT Original-Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15]) by aserv0122.oracle.com (8.13.8/8.13.8) with ESMTP id t87H8Vpr016935; Mon, 7 Sep 2015 17:08:31 GMT In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9 (901082) [OL 12.0.6691.5000 (x86)] X-Source-IP: aserv0022.oracle.com [141.146.126.234] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-Received-From: 156.151.31.81 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:189672 Archived-At: > >> If the function is not supposed to return non-nil if an element is > >> matched but the element itself, then would it be ok? OTOH there would = be > >> again no way to differentiate between no element found and nil being > >> found in the sequence. >=20 > Returning what FUN returned seems like a better choice. > If you need the element matched, then you can simply arrange for FUN > to return the element. Sure, and that is the choice that Common Lisp made: CL `some' looks only for non-nil sequence elements. However: 1. It is common to have existing predicates that you can reuse, and that design makes you wrap them with a lambda, if you want to return the element: (lambda (x) (and (arrayp x) x) versus just arrayp. (A minor point, admittedly.) And IF we want to let `seq-some' also find a nil sequence element: 2. If you "arrange for FUN to return the element", and if the element found is nil (the problem you raised), the calling code still cannot tell whether or not predicate FUN has been satisfied by that element. You would need to then retest the return value using the bare, underlying predicate that FUN wraps. IOW, such a design is OK if all you ever care about is finding a non-nil match, but not if you want to be sure there are no matches (including no matches of nil). 3. The name of the function suggests that it returns an element of the sequence: some element that satisfies the predicate. Nothing in the name suggests that it returns what the function returns. (Another point that is minor.) 4. This is another reason that `member' & compagnie return a cons and not just the element that is a member: distinguish a find of nil from no find. It means that `member' can be used as a general "presence" predicate, whereas, say, `get' cannot (as it does not distinguish the presence of a nil property value from the absence of the property). The typical way to distinguish nil as the thing found from not finding anything is to wrap the thing found in a cons. And if it is sometimes useful to get the value that FUN returns then both that value and the element that satisfies FUN can be returned in a cons: (ELEMENT . VALUE). The first question to ask here is the one suggested in the Subject line: Do we want `seq-some' to find a nil sequence element?