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.