seq-some-p and nil

seq-some-p and nil

[Simen Heggestøyl]

[-- Attachment #1: Type: text/plain, Size: 679 bytes --]

Hi!

Currently it's not possible to use `seq-some-p' to check if a sequence
contains some `nil' value. For instance:

(seq-some-p #'null '(1 2))
     ⇒ nil

Which is good, but:

(seq-some-p #'null '(1 nil 2))
     ⇒ nil

How to distinguish the two cases?

Two solutions come to my mind: 1) Make `seq-some-p' a pure t/nil
predicate, or 2) Make it behave like `some' in Common Lisp, which is
to return the first non-nil value which is returned by an invocation
of the predicate. So in CL:

(some #'null '(1 2))
     ⇒ nil

And:

(some #'null '(1 nil 2))
     ⇒ t

And even:

(some #'1+ '(5 4 3))
     ⇒ 6

What do you think?

-- Simen

[-- Attachment #2: Type: text/html, Size: 1130 bytes --]

Re: seq-some-p and nil

[Stefan Monnier]

> Two solutions come to my mind: 1) Make `seq-some-p' a pure t/nil
> predicate, or 2) Make it behave like `some' in Common Lisp, which is
> to return the first non-nil value which is returned by an invocation
> of the predicate. So in CL:

I think that functions named "<foo>-p" should return values which are
fundamentally booleans, but whose non-nil value is unspecified (they
can return any non-nil value they fancy and the callers should make
assumptions about that non-nil return value).

Other than that, the CL behavior looks sane to me.


        Stefan

Re: seq-some-p and nil

[Artur Malabarba]

2015-09-03 17:42 GMT+01:00 Stefan Monnier <monnier@iro.umontreal.ca>:
>> Two solutions come to my mind: 1) Make `seq-some-p' a pure t/nil
>> predicate, or 2) Make it behave like `some' in Common Lisp, which is
>> to return the first non-nil value which is returned by an invocation
>> of the predicate. So in CL:
>
> I think that functions named "<foo>-p" should return values which are
> fundamentally booleans

Agreed, and that's not the only case.
Both `seq-some-p' and `seq-contains-p' are named as predicates but do
not behave as predicates.

Re: seq-some-p and nil

[John Mastro]

Artur Malabarba <bruce.connor.am@gmail.com> wrote:
> Agreed, and that's not the only case.
> Both `seq-some-p' and `seq-contains-p' are named as predicates but do
> not behave as predicates.

I think `seq-some-p' (or its successor) would also be more useful if it
promised to return the first matching element (the docstring says "any
element", though in practice it does return the first).

-- 
john

RE: seq-some-p and nil

[Drew Adams]

> I think `seq-some-p' (or its successor) would also be more useful if it
> promised to return the first matching element (the docstring says "any
> element", though in practice it does return the first).

Yes, like Common Lisp `some'.

And IMHO, it is better to reserve the suffix `-p' for a function
that does not return an especially useful result, i.e., that
really is used mainly or only as a predicate.

If `seq-some-p' returns a sequence element then it should be
called `seq-some', without the `-p'.

The fact that some functions that return useful non-nil results
other than `t' can be used also as predicates does not mean
that they should systematically be named with suffix `-p'.

That suffix draws attention to the use as a predicate.  A case
such as `some-p' should not do that.  Its name should say that
it returns a sequence element.

RE: seq-some-p and nil

[Nicolas Petton]

[-- Attachment #1: Type: text/plain, Size: 386 bytes --]

Drew Adams <drew.adams@oracle.com> writes:

> And IMHO, it is better to reserve the suffix `-p' for a function
> that does not return an especially useful result, i.e., that
> really is used mainly or only as a predicate.

I agree, I will rename `seq-some-p' and `seq-contains-p' to `seq-some'
and `seq-contains'.

Cheers,
Nico
-- 
Nicolas Petton
http://nicolas-petton.fr

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 512 bytes --]

Re: seq-some-p and nil

[Nicolas Petton]

[-- Attachment #1: Type: text/plain, Size: 565 bytes --]

John Mastro <john.b.mastro@gmail.com> writes:

> Artur Malabarba <bruce.connor.am@gmail.com> wrote:
>> Agreed, and that's not the only case.
>> Both `seq-some-p' and `seq-contains-p' are named as predicates but do
>> not behave as predicates.
>
> I think `seq-some-p' (or its successor) would also be more useful if it
> promised to return the first matching element (the docstring says "any
> element", though in practice it does return the first).

Indeed, I agree.  I will update its docstring.

Nico
-- 
Nicolas Petton
http://nicolas-petton.fr

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 512 bytes --]

Re: seq-some-p and nil

[Mark Oteiza]

Nicolas Petton <nicolas@petton.fr> writes:

> John Mastro <john.b.mastro@gmail.com> writes:
>
>> Artur Malabarba <bruce.connor.am@gmail.com> wrote:
>>> Agreed, and that's not the only case.
>>> Both `seq-some-p' and `seq-contains-p' are named as predicates but do
>>> not behave as predicates.
>>
>> I think `seq-some-p' (or its successor) would also be more useful if it
>> promised to return the first matching element (the docstring says "any
>> element", though in practice it does return the first).
>
> Indeed, I agree.  I will update its docstring.

I also liked seq-some-p returning the matching element over cl-some
returning the value returned by the predicate.

Perhaps there could be a function in seq that preserves this behavior.

Re: seq-some-p and nil

[Nicolas Petton]

[-- Attachment #1: Type: text/plain, Size: 361 bytes --]

Mark Oteiza <mvoteiza@udel.edu> writes:

> I also liked seq-some-p returning the matching element over cl-some
> returning the value returned by the predicate.
>
> Perhaps there could be a function in seq that preserves this behavior.

Me too, and I thik I will add it back under a different name.

Nico
-- 
Nicolas Petton
http://nicolas-petton.fr

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 512 bytes --]

Re: seq-some-p and nil

[Stefan Monnier]

> I also liked seq-some-p returning the matching element over cl-some
> returning the value returned by the predicate.

But if the matched element is nil ...


        Stefan

Re: seq-some-p and nil

[Nicolas Petton]

[-- Attachment #1: Type: text/plain, Size: 513 bytes --]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> I also liked seq-some-p returning the matching element over cl-some
>> returning the value returned by the predicate.
>
> But if the matched element is nil ...

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.

Nico
-- 
Nicolas Petton
http://nicolas-petton.fr

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 512 bytes --]

RE: seq-some-p and nil

[Drew Adams]

> >> I also liked seq-some-p returning the matching element over cl-some
> >> returning the value returned by the predicate.
> >
> > But if the matched element is nil ...
> 
> 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.

1. That's too big a weakness.  It means that `seq-some' cannot
be used as a predicate.  (Again, lose the suffix `-p' if the
return value is important as something other than a Boolean.)

2. You can return both the sequence element and the value of the
predicate applied to it, as a cons: (ELEMENT . VALUE).

If the element is nil then the return value is (nil . VALUE).

That gives you both kinds of info, at the cost of a cons and
the trouble to dig out what you need from the cons.

3. If you never care about the VALUE, you could just return a
cons with the sequence element.  For nil the return value
would then be (nil).

#2 sounds reasonable.

Re: seq-some-p and nil

[Stefan Monnier]

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


        Stefan

Re: seq-some-p and nil

[Mark Oteiza]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

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

Or have a function which returns the matching ELT and have seq-some and
friends use said function and apply PRED to its return value.

RE: seq-some-p and nil

[Drew Adams]

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

[Nicolas Petton]

[-- Attachment #1: Type: text/plain, Size: 1153 bytes --]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

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

There is a misunderstanding here I think.

The way I see it, they are two different functions: the (new) seq-some,
and this other function that is now missing in seq, with the new
implementation of `seq-some'.

This new function would be used to find an element in a seq using a
predicate.  CL has `find-if,' Scheme has `find', Clojure has `some',
Smalltalk has `detect:', etc.

Also, both the CL and scheme versions have the nil value ambiguity, but
since these functions are not supposed to return the logical truth on a
match, it is in my opinion fine.

I think I could name this function `seq-find'.

Cheers,
Nico
-- 
Nicolas Petton
http://nicolas-petton.fr

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 512 bytes --]

Re: seq-some-p and nil

[Stefan Monnier]

>> 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.
> There is a misunderstanding here I think.
> The way I see it, they are two different functions: the (new) seq-some,
> and this other function that is now missing in seq, with the new
> implementation of `seq-some'.

I don't think so.  Both functions can be one and the same.
If you really want seq-find, you can define it as

  (defun seq-find (pred seq)
    (seq-some (lambda (x) (and (funcall pred x) x)) seq))

But I'm far from convinced it's worth having them both,


        Stefan

Re: seq-some-p and nil

[Nicolas Petton]

[-- Attachment #1: Type: text/plain, Size: 1081 bytes --]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> 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.
>> There is a misunderstanding here I think.
>> The way I see it, they are two different functions: the (new) seq-some,
>> and this other function that is now missing in seq, with the new
>> implementation of `seq-some'.
>
> I don't think so.  Both functions can be one and the same.
> If you really want seq-find, you can define it as
>
>   (defun seq-find (pred seq)
>     (seq-some (lambda (x) (and (funcall pred x) x)) seq))
>
> But I'm far from convinced it's worth having them both,

Can you elaborate on why you think it's not worth it?

IMO, finding an element in a sequence is a very common operation, and to
do that now with `seq-some' one would have to add extra code to the
lambda each time, which I find cumbersome, but more importantly is not
very good in terms of code reuse.

Nico
-- 
Nicolas Petton
http://nicolas-petton.fr

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 512 bytes --]

Re: seq-some-p and nil

[Stefan Monnier]

> Can you elaborate on why you think it's not worth it?

> IMO, finding an element in a sequence is a very common operation,

Conceptually, yes, but if you take into account the details of how you
specify which element you want, as well as what you want to do with it,
then in most cases, I think the code ends up just as simple with
seq-some as with seq-find.

And using seq-some doesn't have the weird nil corner case.
And defining seq-find as I did means it's always less efficient.
And defining seq-find more efficiently means code duplication.


        Stefan

Re: seq-some-p and nil

[Nicolas Petton]

[-- Attachment #1: Type: text/plain, Size: 996 bytes --]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Can you elaborate on why you think it's not worth it?
>
>> IMO, finding an element in a sequence is a very common operation,
>
> Conceptually, yes, but if you take into account the details of how you
> specify which element you want, as well as what you want to do with it,
> then in most cases, I think the code ends up just as simple with
> seq-some as with seq-find.

I don't follow.  How can the code end up just as simple when finding an
element matching a predicate?

To make things easier to understand, I'm taking the example of finding
the first odd number in a seq:

    (seq-some (lambda (elt) (and (oddp elt) elt))
              '(0 1 2 3))

    (seq-find #'oddp '(0 1 2 3))

The first version is not only much harder to read, it also IMO shows
that the lambda mostly re-implement what a `seq-find' function should
provide by default in the library.

Nico
-- 
Nicolas Petton
http://nicolas-petton.fr

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 512 bytes --]

Re: seq-some-p and nil

[Stefan Monnier]

>> then in most cases, I think the code ends up just as simple with
>> seq-some as with seq-find.
[...]
> To make things easier to understand, I'm taking the example of finding
> the first odd number in a seq:

I've never needed to do that.


        Stefan

Re: seq-some-p and nil

[David Kastrup]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> then in most cases, I think the code ends up just as simple with
>>> seq-some as with seq-find.
> [...]
>> To make things easier to understand, I'm taking the example of finding
>> the first odd number in a seq:
>
> I've never needed to do that.

Marvelous.

-- 
David Kastrup

RE: seq-some-p and nil

[Drew Adams]

> >> To make things easier to understand, I'm taking the example of finding
> >> the first odd number in a seq:
> >
> > I've never needed to do that.
> 
> Marvelous.

;-)

Was there something wrong with the suggestion to return,
as the non-nil value, a cons (ELEMENT . VALUE)?

(Where ELEMENT is the sequence element that satisfies the
predicate, and VALUE is the return value of the predicate
for that element.)

That gives you "some" element that satisfies the predicate
(the first such).  And it gives you the result of the test.
Each of these can be useful, depending on the context.

RE: seq-some-p and nil

[Nicolas Petton]

[-- Attachment #1: Type: text/plain, Size: 917 bytes --]

Drew Adams <drew.adams@oracle.com> writes:

>> >> To make things easier to understand, I'm taking the example of finding
>> >> the first odd number in a seq:
>> >
>> > I've never needed to do that.
>> 
>> Marvelous.
>
> ;-)
>
> Was there something wrong with the suggestion to return,
> as the non-nil value, a cons (ELEMENT . VALUE)?
>
> (Where ELEMENT is the sequence element that satisfies the
> predicate, and VALUE is the return value of the predicate
> for that element.)
>
> That gives you "some" element that satisfies the predicate
> (the first such).  And it gives you the result of the test.
> Each of these can be useful, depending on the context.

It would work, and I believe Scheme has a similar function, but I don't
want seq-some to have this extra complexity.  It could be another
function though, just like in Scheme.

Nico
-- 
Nicolas Petton
http://nicolas-petton.fr

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 512 bytes --]

RE: seq-some-p and nil

[Drew Adams]

> > Was there something wrong with the suggestion to return,
> > as the non-nil value, a cons (ELEMENT . VALUE)?
> >
> > (Where ELEMENT is the sequence element that satisfies the
> > predicate, and VALUE is the return value of the predicate
> > for that element.)
> >
> > That gives you "some" element that satisfies the predicate
> > (the first such).  And it gives you the result of the test.
> > Each of these can be useful, depending on the context.
> 
> It would work, and I believe Scheme has a similar function, but I don't
> want seq-some to have this extra complexity.  It could be another
> function though, just like in Scheme.

What extra complexity?  It creates one cons cell which has as its
car and cdr things that presumably already exist.

I realize you are dealing with general sequences, and that the
sequence code can be complex, but the cons part of it, as the return
value, should be simple, no?  Isn't it true for all sequence types
supported, that the car and cdr will exist after the predicate is
called, and so they can just be pointed to by the cons?

For lists only, this is what I use, FWIW:

(defun zz-some (predicate list)
  "Return non-nil if PREDICATE applied to some element of LIST is true.
The value returned is a cons, (ELEMENT . VALUE), where ELEMENT is the
first list element that satisfies PREDICATE and VALUE is the value of
PREDICATE applied to ELEMENT."
  (let (elt val)
    (catch 'zz-some
      (while list
        (when (setq val  (funcall predicate (setq elt  (pop list))))
          (throw 'zz-some (cons elt val))))
      nil)))

RE: seq-some-p and nil

[Nicolas Petton]

[-- Attachment #1: Type: text/plain, Size: 1079 bytes --]

Drew Adams <drew.adams@oracle.com> writes:

>> > Was there something wrong with the suggestion to return,
>> > as the non-nil value, a cons (ELEMENT . VALUE)?
>> >
>> > (Where ELEMENT is the sequence element that satisfies the
>> > predicate, and VALUE is the return value of the predicate
>> > for that element.)
>> >
>> > That gives you "some" element that satisfies the predicate
>> > (the first such).  And it gives you the result of the test.
>> > Each of these can be useful, depending on the context.
>> 
>> It would work, and I believe Scheme has a similar function, but I don't
>> want seq-some to have this extra complexity.  It could be another
>> function though, just like in Scheme.
>
> What extra complexity?  It creates one cons cell which has as its
> car and cdr things that presumably already exist.

I meant extra complexity for the user.  If seq-some was returning a
value, I wouldn't expect it to be a cons cell, I'd almost always want
the element of the sequence straight away.

Nico
-- 
Nicolas Petton
http://nicolas-petton.fr

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 512 bytes --]

RE: seq-some-p and nil

[Drew Adams]

> I meant extra complexity for the user.  If seq-some was returning a
> value, I wouldn't expect it to be a cons cell, I'd almost always want
> the element of the sequence straight away.

Well, yes.  But what if the user wants the value returned by the
function?  And what if the element is nil?

1. You need a way to always return non-nil when an element is found.
   This includes the case where the element is nil - you cannot
   just return nil as the element.

2. You (I) want to be able to use the the `some' function to
   either get the element or get the return value of the predicate,
   which can be an arbitrary function that could return a rich value.
   Or both: get and use both the element and the value.

Conclusion: return both the element and the predicate value, as
a non-nil Lisp value.  (ELEMENT . VALUE) is one such simple value.

Re: seq-some-p and nil

[Stefan Monnier]

seq-some already solves those problems.  The user can provide a FUN that
returns a cons if she so wishes.  It's simple and general.


        Stefan

RE: seq-some-p and nil

[Drew Adams]

> seq-some already solves those problems.  The user can provide a FUN that
> returns a cons if she so wishes.  It's simple and general.

So is assembly language simple and general.  Why make callers of
`seq-some' deal with the nil-value-vs-not-found issue and wrap
existing predicates they want to reuse with cruft, just to get
the desired effect?  Why not just have `seq-some' DTRT, always?

Re: seq-some-p and nil

[Stefan Monnier]

> So is assembly language simple and general.  Why make callers of
> `seq-some' deal with the nil-value-vs-not-found issue

There's no such issue with seq-some.  It only affects seq-find.


        Stefan

RE: seq-some-p and nil

[Drew Adams]

> > Why make callers of `seq-some' deal with the nil-value-vs-not-found
> > issue and...
> 
> There's no such issue with seq-some.  It only affects seq-find.

Oh, right, because you have not done what Nico proposed wrt returning
the element.  Fair enough.

The second part of what I wrote, which you elided, still applies:

Why make callers of `seq-some' ... wrap existing predicates they want
to reuse with cruft, just to get the desired effect?  Why not just
have `seq-some' DTRT, always?

RE: seq-some-p and nil

[Nicolas Petton]

[-- Attachment #1: Type: text/plain, Size: 1016 bytes --]

Drew Adams <drew.adams@oracle.com> writes:

>> I meant extra complexity for the user.  If seq-some was returning a
>> value, I wouldn't expect it to be a cons cell, I'd almost always want
>> the element of the sequence straight away.
>
> Well, yes.  But what if the user wants the value returned by the
> function?

`seq-some', as it is now defined, is the right function to use.

> And what if the element is nil?

Then maybe seq-find is not the right function to use.  Or seq-find
could, as Stephen suggested, take an optional sentinel argument for
these very rare cases.

I know that your suggestion also fixes the semantic issue, but I don't
like the cost it adds.  99% of the times, you will want the element you
searched for in the seq.  I think using seq-find should remain simple
and straightforward, just like `find-if' in CL.  I also had another look
at the Clojure and Scheme equivalents, and they both have a similar
corner case, though in the case of Clojure, `true' is returned instead
of `nil'.

Nico

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 512 bytes --]

Re: seq-some-p and nil

[Stefan Monnier]

>>>> then in most cases, I think the code ends up just as simple with
>>>> seq-some as with seq-find.
>> [...]
>>> To make things easier to understand, I'm taking the example of finding
>>> the first odd number in a seq:
>> I've never needed to do that.
> Marvelous.

You did notice the "most" qualifier, right?


        Stefan

Re: seq-some-p and nil

[David Kastrup]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>>>> then in most cases, I think the code ends up just as simple with
>>>>> seq-some as with seq-find.
>>> [...]
>>>> To make things easier to understand, I'm taking the example of finding
>>>> the first odd number in a seq:
>>> I've never needed to do that.
>> Marvelous.
>
> You did notice the "most" qualifier, right?

Oh, that changes _everything_, _everything_ I am sure.

When at that time in my life when I had been attending lectures some
professor would have stated

"As an example, let's see how to take the inverse of the matrix
( 1  2 )
( 2  1 )"

I would never felt the urge to tell the professor that this is a
particular matrix I never actually needed to invert.  I'm pretty sure
that the entire lecture room would have bursted into laughter at me
volunteering this particular bit of information and considering it
important enough to ask for everybody's attention.

It is an example.  Nobody expects life-shattering relevance of that
example for any purpose but being an example.

-- 
David Kastrup

Re: seq-some-p and nil

[Nicolas Petton]

[-- Attachment #1: Type: text/plain, Size: 449 bytes --]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> then in most cases, I think the code ends up just as simple with
>>> seq-some as with seq-find.
> [...]
>> To make things easier to understand, I'm taking the example of finding
>> the first odd number in a seq:
>
> I've never needed to do that.

That was just an example.  You never needed to find an element from
a sequence?

Nico
-- 
Nicolas Petton
http://nicolas-petton.fr

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 512 bytes --]

Re: seq-some-p and nil

[David Kastrup]

Nicolas Petton <nicolas@petton.fr> writes:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>>>> then in most cases, I think the code ends up just as simple with
>>>> seq-some as with seq-find.
>> [...]
>>> To make things easier to understand, I'm taking the example of finding
>>> the first odd number in a seq:
>>
>> I've never needed to do that.
>
> That was just an example.

<URL:http://www.smbc-comics.com/index.php?id=3855>

-- 
David Kastrup

Re: seq-some-p and nil

[Stefan Monnier]

>>>> then in most cases, I think the code ends up just as simple with
>>>> seq-some as with seq-find.
>> [...]
>>> To make things easier to understand, I'm taking the example of finding
>>> the first odd number in a seq:
>> I've never needed to do that.
> That was just an example.  You never needed to find an element from
> a sequence?

On its own, no; only to do something with it.  So I think in many cases
you can cheaply move the equivalent of (and <pred> x) into the seq-some
search, in many other cases you can instead cheaply move the processing
of the result into the seq-some search.

Of course, there are still remaining cases where you'll end up needing
(lambda (x) (if (my-pred x) x)), but in my experience, it's not frequent
enough to make a seq-find useful.

This said, we have lots of such functions I find useless, so don't let
that prevent you from adding it to seq.el.  Just don't forget to warn
about its little semantic problem with nil in the docstring.


        Stefan

Re: seq-some-p and nil

[Nicolas Petton]

[-- Attachment #1: Type: text/plain, Size: 282 bytes --]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> This said, we have lots of such functions I find useless, so don't let
> that prevent you from adding it to seq.el.  Just don't forget to warn
> about its little semantic problem with nil in the docstring.

I will do that.

Nico

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 512 bytes --]

Re: seq-some-p and nil

[Nicolas Petton]

[-- Attachment #1: Type: text/plain, Size: 569 bytes --]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> And using seq-some doesn't have the weird nil corner case.

Just like CL's `find-if' and Scheme's `find', if one is looking for nil,
and if `seq-find' is not supposed to return a boolean, then it's fine
with me.  You'd always have `seq-some' if it's an issue in a specific
scenario anyway.

> And defining seq-find as I did means it's always less efficient.

It's ok, I think, for `seq-find' to reuse `seq-some'.  You can't both
want to remove code duplication and be as efficient as the code you are
reusing.

Nico

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 512 bytes --]

Re: seq-some-p and nil

[Mark Oteiza]

On 08/09/15 at 03:21pm, Nicolas Petton wrote:
> > And defining seq-find as I did means it's always less efficient.
> 
> It's ok, I think, for `seq-find' to reuse `seq-some'.  You can't both
> want to remove code duplication and be as efficient as the code you are
> reusing.

Why not reuse seq-find in seq-some? It at least looks (to me) a little
cleaner than the other way around

  (defun seq-some (pred seq)
    (funcall pred (seq-find (pred seq)))

Re: seq-some-p and nil

[Stefan Monnier]

>   (defun seq-some (pred seq)
>     (funcall pred (seq-find (pred seq)))

But that fails for the case where the element found is nil.


        Stefan

Re: seq-some-p and nil

[Mark Oteiza]

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

  (cl-defgeneric seq-find (pred seq)
    (catch 'seq--break
      (seq-doseq (elt seq)
        (when (funcall pred elt)
          (throw 'seq--break elt)))
      nil))

  (cl-defgeneric seq-some (pred seq)
    (funcall pred (seq-find pred seq)))

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

Re: seq-some-p and nil

[Stephen J. Turnbull]

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.

Re: seq-some-p and nil

[Mark Oteiza]

On 09/09/15 at 01:28pm, Stephen J. Turnbull wrote:
> 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
> 
> 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.

Thanks, that makes sense. I misunderstood

Re: seq-some-p and nil

[Nicolas Petton]

[-- Attachment #1: Type: text/plain, Size: 211 bytes --]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Returning what FUN returned seems like a better choice.

It's already what the new seq-some does.

Nico
-- 
Nicolas Petton
http://nicolas-petton.fr

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 512 bytes --]

Re: seq-some-p and nil

[Nicolas Petton]

[-- Attachment #1: Type: text/plain, Size: 465 bytes --]

Simen Heggestøyl <simenheg@gmail.com> writes:

> Hi!

Hi!

> Currently it's not possible to use `seq-some-p' to check if a sequence
> contains some `nil' value. For instance:
>
> (seq-some-p #'null '(1 2))
>      ⇒ nil
>
> Which is good, but:
>
> (seq-some-p #'null '(1 nil 2))
>      ⇒ nil

This is definitely a bug, I will fix it! (I will copy the behavior of
`some' in CL).

Cheers,
Nico
-- 
Nicolas Petton
http://nicolas-petton.fr

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 512 bytes --]

Re: seq-some-p and nil

[Simen Heggestøyl]

[-- Attachment #1: Type: text/plain, Size: 567 bytes --]

On Thu, Sep 3, 2015 at 9:40 PM, Nicolas Petton <nicolas@petton.fr> 
wrote:
> This is definitely a bug, I will fix it! (I will copy the behavior of
> `some' in CL).

Thanks Nicolas, the fix looks good!

While we're on it, wouldn't seq-some be even more powerful if it
guaranteed to return the value from the first matched element? Or
would that somehow be difficult for some kinds of seqs?

(By the way, I saw your presentation about seq.el on en EmacsConf. It
was interesting, thanks for holding it. That was also how I spotted
the bug in the first place.)

-- Simen

[-- Attachment #2: Type: text/html, Size: 803 bytes --]

Re: seq-some-p and nil

[Nicolas Petton]

[-- Attachment #1: Type: text/plain, Size: 369 bytes --]

Simen Heggestøyl <simenheg@gmail.com> writes:
>
> While we're on it, wouldn't seq-some be even more powerful if it
> guaranteed to return the value from the first matched element? Or
> would that somehow be difficult for some kinds of seqs?

I added another function seq-find that does just that.

Cheers,
Nico
-- 
Nicolas Petton
http://nicolas-petton.fr

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 512 bytes --]

Re: seq-some-p and nil

[Simen Heggestøyl]

[-- Attachment #1: Type: text/plain, Size: 816 bytes --]

On Fri, Sep 11, 2015 at 12:12 AM, Nicolas Petton <nicolas@petton.fr> 
wrote:
> Simen Heggestøyl <simenheg@gmail.com> writes:
>> 
>>  While we're on it, wouldn't seq-some be even more powerful if it
>>  guaranteed to return the value from the first matched element? Or
>>  would that somehow be difficult for some kinds of seqs?
> 
> I added another function seq-find that does just that.
> 
> Cheers,
> Nico
> --
> Nicolas Petton
> http://nicolas-petton.fr

Ah, sorry, I should have been clearer. What I meant was that it could
guarantee to return the *first* non-nil value that resulted from
applying the predicate, like in CL.

So for instance, (seq-some #'1+ '(1 3 5)) could guarantee to return 2,
not 4 or 6.

(And still (seq-some #'null '(1 nil 2)) ⇒ t, unlike seq-find).

-- Simen

[-- Attachment #2: Type: text/html, Size: 1137 bytes --]

Re: seq-some-p and nil

[Nicolas Petton]

[-- Attachment #1: Type: text/plain, Size: 569 bytes --]

Simen Heggestøyl <simenheg@gmail.com> writes:

Hi Simen,

> Ah, sorry, I should have been clearer. What I meant was that it could
> guarantee to return the *first* non-nil value that resulted from
> applying the predicate, like in CL.
>
> So for instance, (seq-some #'1+ '(1 3 5)) could guarantee to return 2,
> not 4 or 6.

You lost me.  Isn't that exactly what `seq-some' does?

    (seq-some #'1+ '(1 3 5)) ;; => 2

Or did you mean that the documentation of `seq-some' should state that
`seq-some' returns the first non-nil value?

Cheers,
Nico

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 512 bytes --]

Re: seq-some-p and nil

[David Kastrup]

Nicolas Petton <nicolas@petton.fr> writes:

> Simen Heggestøyl <simenheg@gmail.com> writes:
>
> Hi Simen,
>
>> Ah, sorry, I should have been clearer. What I meant was that it could
>> guarantee to return the *first* non-nil value that resulted from
>> applying the predicate, like in CL.
>>
>> So for instance, (seq-some #'1+ '(1 3 5)) could guarantee to return 2,
>> not 4 or 6.
>
> You lost me.  Isn't that exactly what `seq-some' does?
>
>     (seq-some #'1+ '(1 3 5)) ;; => 2
>
> Or did you mean that the documentation of `seq-some' should state that
> `seq-some' returns the first non-nil value?

Yes, I think that's what he wants in order to have some reassurance
against the "I've altered the semantics.  Pray I don't alter them any
further." phenomenon.

-- 
David Kastrup

Re: seq-some-p and nil

[Simen Heggestøyl]

[-- Attachment #1: Type: text/plain, Size: 646 bytes --]



On Wed, Sep 23, 2015 at 10:38 AM, Nicolas Petton <nicolas@petton.fr> 
wrote:
> Simen Heggestøyl <simenheg@gmail.com> writes:
> 
> Hi Simen,
> 
>>  Ah, sorry, I should have been clearer. What I meant was that it 
>> could
>>  guarantee to return the *first* non-nil value that resulted from
>>  applying the predicate, like in CL.
>> 
>>  So for instance, (seq-some #'1+ '(1 3 5)) could guarantee to return 
>> 2,
>>  not 4 or 6.
> 
> [...]
> Or did you mean that the documentation of `seq-some' should state that
> `seq-some' returns the first non-nil value?
> 
> Cheers,
> Nico

Yes, that's what I meant.

-- Simen

[-- Attachment #2: Type: text/html, Size: 811 bytes --]

Re: seq-some-p and nil

[Nicolas Petton]

[-- Attachment #1: Type: text/plain, Size: 270 bytes --]

Simen Heggestøyl <simenheg@gmail.com> writes:

>> Or did you mean that the documentation of `seq-some' should state that
>> `seq-some' returns the first non-nil value?
>> 
>
> Yes, that's what I meant.

Ok, that makes sense, I'll update the docstring.

Nico

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 512 bytes --]

Re: seq-some-p and nil

[Nicolas Petton]

[-- Attachment #1: Type: text/plain, Size: 287 bytes --]

Simen Heggestøyl <simenheg@gmail.com> writes:

> So for instance, (seq-some #'1+ '(1 3 5)) could guarantee to return 2,
> not 4 or 6.

I just installed a better docstring and updated the documentation for
seq-some.

Cheers,
Nico
-- 
Nicolas Petton
http://nicolas-petton.fr

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 512 bytes --]