[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
element?
- RE: seq-some-p and nil, (continued)
- Re: seq-some-p and nil, Nicolas Petton, 2015/09/03
- Re: seq-some-p and nil, Mark Oteiza, 2015/09/05
- Re: seq-some-p and nil, Nicolas Petton, 2015/09/06
- Re: seq-some-p and nil, Stefan Monnier, 2015/09/06
- Re: seq-some-p and nil, Nicolas Petton, 2015/09/07
- RE: seq-some-p and nil, Drew Adams, 2015/09/07
- Re: seq-some-p and nil, Stefan Monnier, 2015/09/07
- Re: seq-some-p and nil, Mark Oteiza, 2015/09/07
- RE: seq-some-p and nil,
Drew Adams <=
- Re: seq-some-p and nil, Nicolas Petton, 2015/09/07
- Re: seq-some-p and nil, Stefan Monnier, 2015/09/07
- Re: seq-some-p and nil, Nicolas Petton, 2015/09/08
- Re: seq-some-p and nil, Stefan Monnier, 2015/09/08
- Re: seq-some-p and nil, Nicolas Petton, 2015/09/08
- Re: seq-some-p and nil, Stefan Monnier, 2015/09/08
- Re: seq-some-p and nil, David Kastrup, 2015/09/08
- RE: seq-some-p and nil, Drew Adams, 2015/09/08
- RE: seq-some-p and nil, Nicolas Petton, 2015/09/08
- RE: seq-some-p and nil, Drew Adams, 2015/09/08