plkrueger at comcast.net
Mon Dec 7 19:42:39 PST 2009
Yes, ignore errors would likely work; I could incorporate it into the
test. I thought about that, but it feels like the wrong thing to do
because in fact it is always the case for my sequence that there is a
last element where the test is satisfied prior to encountering the
element where it isn't.
I guess the upshot is that I required a serialized search for my
algorithm and the Lisp construct that I was using just doesn't
guarantee that serialization. Fair enough, I'll just use or construct
one that does.
I certainly recognize what Gary is saying about parallel
implementations being in our future. For constructs that don't promise
serialization, performance can potentially be improved. Only
"potentially" because parallel algorithms are notoriously difficult to
get correct and often you get counterintuitive performance results. I
spent a lot of time in the supercomputer world where this problem
comes up all the time.
I suspect that there are more than a few Lisp programs that take
advantage of the accidental serialization that is part of most
implementations. These will break, of course, when those new parallel
implementations finally arrive. And we'll likely need new constructs
to enforce serialization when we need it. Maybe we'll have to add
Software Transactional Memory (STM) or something like it to Lisp.
Should be fun to see how it shakes out.
On Dec 7, 2009, at 6:12 PM, Ron Garret wrote:
> On Dec 7, 2009, at 3:51 PM, Tim Bradshaw wrote:
>> On 7 Dec 2009, at 23:38, Paul Krueger wrote:
>>> 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
>> Can that be right? I think you can always pass something like
>> (lambda (thing)
>> (and (test-for-my-predicate-not-causing-error-p thing)
>> (my-predicate-which-may-error thing)))
> or even
> (lambda (thing) (ignore-errors (original-predicate thing)))
> Still sounds to me like you have a design problem. But what do I
More information about the Openmcl-devel