[Openmcl-devel] bug?

[Gary Byers]

(FIND-IF TEST SEQ :FROM-END T) returns the rightmost element of SEQ for
which TEST returns true.  Whether the elements of SEQ are processed
right-to-left, left-to-right, inside-out, outside-in, ... is unspecified.

If SEQ is a vector, then it's somewhat likely that the fastest way to
find that rightmost matching element is to process SEQ's elements in
descending order, but that's not generally practical for lists (or is
at least likely to have substantially higher costs associated with
it.)

At some point in the (hopefull not-too-distant) future, the fastest
way to do some kinds of FIND operations would probably be "in
parallel", and it's good that (by luck or design) the CL spec doesn't
say anything that would make this impossible.

You don't generally know anything about the order in which the
sequence's elements will be processed by FIND-IF or similar
functions; if you make assumptions about that and reality doesn't
match those assumptions, it's generally not reality's fault ...



On Mon, 7 Dec 2009, Paul Krueger wrote:

> Is the following a bug or does the standard permit the following
> behavior?
>
> Welcome to Clozure Common Lisp Version 1.5-dev-r13174M-trunk
> (DarwinX8664)!
> ?  (setf ls (list 1 2 3 'a 0 1 2 3))
> (1 2 3 A 0 1 2 3)
> ? (plusp 0)
> NIL
> ? (find-if-not #'plusp ls :from-end t)
> > Error: value A is not of the expected type REAL.
> > While executing: PLUSP, in process Listener-2(7).
> > Type cmd-. to abort, cmd-\ for a list of available restarts.
> > Type :? for other options.
> 1 >
> ?
>
> I guess I would have expected that if the ":from-end t" was honored
> that #'plusp would never be called on the 'a element, but obviously
> that isn't the case.
>
> And if you happen to use a test that has side-effects, e.g.
>
> ? (defvar *count* 0)
> *COUNT*
> ? (defun #'plusp-with-side-effects (arg)
>     (when (plusp arg)
>       (incf *count*)))
> ? (setf ls2 '(1 2 3 0 1 2 3))
> (1 2 3 0 1 2 3)
> ? (find-if #'plusp-with-side-effects ls2 :from-end t)
> 3
> ? *count*
> 6
> ?
>
> (trying to count how many positive numbers occur at the end of the
> list) then you may not get what you expect.
>
> You don't see this behavior if you search from the beginning of a list
> or search backward through an array. It's as if someone decided that
> since you have to traverse the list to find the end anyway that you
> might as well run the test as you go. I suppose I can nreverse my list
> and search forward to avoid this now that I know what it's doing ...
>
> Paul
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
>
>