[Openmcl-devel] bug?

[Robert Goldman]

Ben Hyde wrote:
> On Dec 7, 2009, at 5:36 PM, 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.
> 
> While the name ":from-end" certainly suggests the behavior you and I'd  
> expect, the spec reads "If from-end is true, then the result is the  
> rightmost element that satisfies the test." and do seems to license  
> that behavior.   The portablity gods may reward you if you suppress  
> your very natural expectations.  SBCL exhibits the same behavior.

I couldn't find any discussion of this in the CLHS for find, but if you
look at the page for SEARCH, you find something that clearly suggests
that this is not a bug:

The implementation may choose to search sequence-2 in any order; there
is no guarantee on the number of times the test is made. For example,
when start-end is true, the sequence might actually be searched from
left to right instead of from right to left (but in either case would
return the rightmost matching subsequence).

>From http://www.lispworks.com/documentation/HyperSpec/Body/f_search.htm

They go out fo their way to tell us that search isn't constrained to
search in any particular order.  I wonder why they didn't tell us
something similar about FIND....

best,
r