rpgoldman at sift.info
Mon Dec 7 23:03:57 UTC 2009
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
>> Welcome to Clozure Common Lisp Version 1.5-dev-r13174M-trunk
>> ? (setf ls (list 1 2 3 'a 0 1 2 3))
>> (1 2 3 A 0 1 2 3)
>> ? (plusp 0)
>> ? (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).
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....
More information about the Openmcl-devel