From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Re: seq-some-p and nil Date: Wed, 09 Sep 2015 13:28:48 +0900 Message-ID: <878u8g1ain.fsf@uwakimon.sk.tsukuba.ac.jp> References: <878u8i69ok.fsf@petton.fr> <674102d7-0e97-478a-af05-ca6d82c17c28@default> <87mvwym01x.fsf@petton.fr> <87h9n5mloa.fsf@petton.fr> <87zj0xkpx0.fsf@petton.fr> <20150908133729.GA20184@holos> <20150909021959.GA1494@holos> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Trace: ger.gmane.org 1441772958 4268 80.91.229.3 (9 Sep 2015 04:29:18 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 9 Sep 2015 04:29:18 +0000 (UTC) Cc: Nicolas Petton , Stefan Monnier , Drew Adams , emacs-devel@gnu.org To: Mark Oteiza Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Sep 09 06:29:11 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 1ZZX0P-0005xP-3b for ged-emacs-devel@m.gmane.org; Wed, 09 Sep 2015 06:29:09 +0200 Original-Received: from localhost ([::1]:39655 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZZX0O-0006Q8-CJ for ged-emacs-devel@m.gmane.org; Wed, 09 Sep 2015 00:29:08 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45539) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZZX0C-0006Q1-8a for emacs-devel@gnu.org; Wed, 09 Sep 2015 00:28:57 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZZX08-0004SY-Hr for emacs-devel@gnu.org; Wed, 09 Sep 2015 00:28:55 -0400 Original-Received: from shako.sk.tsukuba.ac.jp ([130.158.97.161]:52418) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZZX08-0004RY-7f for emacs-devel@gnu.org; Wed, 09 Sep 2015 00:28:52 -0400 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id 2C08E1C38CC; Wed, 9 Sep 2015 13:27:42 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id DA94812036E; Wed, 9 Sep 2015 13:28:48 +0900 (JST) In-Reply-To: <20150909021959.GA1494@holos> X-Mailer: VM undefined under 21.5 (beta34) "kale" ffb5abc8dc4e XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x (barebone) [generic] [fuzzy] X-Received-From: 130.158.97.161 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:189752 Archived-At: Mark Oteiza writes: > On 08/09/15 at 01:50pm, Stefan Monnier wrote: > > > (defun seq-some (pred seq) > > > (funcall pred (seq-find (pred seq))) > > > > But that fails for the case where the element found is nil. > > Works as expected [...] > (seq-find 'null [1 2 nil]) > ;; => nil > > (seq-some 'null [1 2 nil]) > ;; => t > > It's not a "semantic problem" or a "corner case", if one is really > curious if their sequence has a nil value, seq-find isn't the way to > find out. You have a test coverage problem. (seq-find 'null [1 2]) ;; => nil (seq-some 'null [1 2]) ;; => t I suppose this is the corner case Stefan meant, in the sense that when seq-find "finds" (ie, "returns") nil it's impossible to distinguish finding nil from not finding nil. There are many ways to implement the distinction. One is to create an uninterned symbol and return that from seq-find-internal, then define seq-find and seq-some in terms of seq-find-internal. I suppose it's more elegant to use a multiple-value technique (ie, return a cons since Emacs doesn't have Common Lisp-style multiple values). This could be done in the -internal function or in the exported API as Drew (IIRC) suggested. You could use the get/find convention used occasionally in Emacs, where the get-foo version signals an error and find-foo returns nil. Then find can be defined in terms of get with an error handler for the not-found error. (This is mostly used in cases where the object is typically a blocker if not found though -- condition-case is relatively expensive.) The find version can also take an optional sentinel argument which is an object to return in the not found case. There are so many ways to get this right. Please don't get it wrong.