unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: Mark Oteiza <mvoteiza@udel.edu>,
	Nicolas Petton <nicolas@petton.fr>,
	emacs-devel@gnu.org
Subject: RE: seq-some-p and nil
Date: Mon, 7 Sep 2015 10:08:22 -0700 (PDT)	[thread overview]
Message-ID: <357b0d47-2ad9-4711-a706-3beea4af6166@default> (raw)
In-Reply-To: <jwvvbbml0lc.fsf-monnier+emacs@gnu.org>

> >> 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.
> 
> 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?



  parent reply	other threads:[~2015-09-07 17:08 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-03 15:50 seq-some-p and nil Simen Heggestøyl
2015-09-03 16:42 ` Stefan Monnier
2015-09-03 17:19   ` Artur Malabarba
2015-09-03 17:35     ` John Mastro
2015-09-03 17:50       ` Drew Adams
2015-09-03 19:36         ` Nicolas Petton
2015-09-03 19:45       ` Nicolas Petton
2015-09-06  1:17         ` Mark Oteiza
2015-09-06 20:48           ` Nicolas Petton
2015-09-06 21:46           ` Stefan Monnier
2015-09-07  6:11             ` Nicolas Petton
2015-09-07  8:06               ` Drew Adams
2015-09-07 15:19                 ` Stefan Monnier
2015-09-07 15:23                   ` Mark Oteiza
2015-09-07 17:08                   ` Drew Adams [this message]
2015-09-07 20:44                   ` Nicolas Petton
2015-09-07 22:27                     ` Stefan Monnier
2015-09-08  7:09                       ` Nicolas Petton
2015-09-08 12:36                         ` Stefan Monnier
2015-09-08 13:07                           ` Nicolas Petton
2015-09-08 16:49                             ` Stefan Monnier
2015-09-08 17:01                               ` David Kastrup
2015-09-08 17:08                                 ` Drew Adams
2015-09-08 19:02                                   ` Nicolas Petton
2015-09-08 19:48                                     ` Drew Adams
2015-09-09  7:56                                       ` Nicolas Petton
2015-09-09 13:26                                         ` Drew Adams
2015-09-09 17:45                                           ` Stefan Monnier
2015-09-09 17:53                                             ` Drew Adams
2015-09-09 20:24                                               ` Stefan Monnier
2015-09-09 20:46                                                 ` Drew Adams
2015-09-09 21:44                                           ` Nicolas Petton
2015-09-08 18:43                                 ` Stefan Monnier
2015-09-08 19:03                                   ` David Kastrup
2015-09-08 18:59                               ` Nicolas Petton
2015-09-08 19:06                                 ` David Kastrup
2015-09-08 20:33                                 ` Stefan Monnier
2015-09-09  7:57                                   ` Nicolas Petton
2015-09-08 13:21                           ` Nicolas Petton
2015-09-08 13:37                             ` Mark Oteiza
2015-09-08 17:50                               ` Stefan Monnier
2015-09-09  2:19                                 ` Mark Oteiza
2015-09-09  4:28                                   ` Stephen J. Turnbull
2015-09-09  4:57                                     ` Mark Oteiza
2015-09-07 20:45                   ` Nicolas Petton
2015-09-03 19:40 ` Nicolas Petton
2015-09-10 17:46   ` Simen Heggestøyl
2015-09-10 22:12     ` Nicolas Petton
2015-09-22 17:17       ` Simen Heggestøyl
2015-09-23  8:38         ` Nicolas Petton
2015-09-23  8:44           ` David Kastrup
2015-09-23  8:48           ` Simen Heggestøyl
2015-09-23 10:57             ` Nicolas Petton
2015-09-28 19:17         ` Nicolas Petton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=357b0d47-2ad9-4711-a706-3beea4af6166@default \
    --to=drew.adams@oracle.com \
    --cc=emacs-devel@gnu.org \
    --cc=monnier@iro.umontreal.ca \
    --cc=mvoteiza@udel.edu \
    --cc=nicolas@petton.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).