[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: seq-some-p and nil

From: Drew Adams
Subject: RE: seq-some-p and nil
Date: Mon, 7 Sep 2015 10:08:22 -0700 (PDT)

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]