[Openmcl-devel] bug?

[Paul Krueger]

On Dec 7, 2009, at 5:02 PM, Ron Garret wrote:

>
> On Dec 7, 2009, at 2:56 PM, 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.
>
> Or change your predicate to (lambda (x) (and (numberp x) (plusp  
> x))).  If you are relying on there being an element in the list that  
> satisfies the predicate before you get to one that causes an error  
> you're almost certainly doing something wrong independent of any  
> portability issues.
>
> rg
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel

So I accept all the explanations and will not count on this ordering,  
but in direct response to Ron's suggestion I'll just say that my  
example was a much simplified version of the real problem that I ran  
into and in that case there is no other predicate that I can run on my  
list element to guarantee that it will not cause an error when the  
test is run on it. But it's not wrong (if the ordering is followed)  
because there IS a guarantee that my test predicate will be satisfied  
just prior to encountering the element that causes the error; it's  
only a matter of discovering where that occurs. It's a long story that  
I won't go into here, but I've now reordered my search to avoid the  
problem. Of course this too depends on functionality that isn't  
guaranteed. Thanks for the responses.

Paul