On 2010-04-04, at 2:47 PM, Mark Engelberg wrote:
> I don't understand why you need to "get rid of the delay" once it has been
> updated. Delays are cheap; why not just be consistent about having your
> data be a ref of a delay? It will keep your code simpler, and that's well
> worth it.
That's
Rich has said that he intentionally didn't want to provide a uniform
interface for setting and altering reference-like objects, and I agree
with him. It wouldn't be difficult to have to have a function that
calls send on agents, swap! on atoms, set! on vars and ref-set on
refs. But it would give th
I don't understand why you need to "get rid of the delay" once it has been
updated. Delays are cheap; why not just be consistent about having your
data be a ref of a delay? It will keep your code simpler, and that's well
worth it.
--
You received this message because you are subscribed to the G
On 2010-04-04, at 11:15 AM, Per Vognsen wrote:
> Interesting question. Here's something I whipped up in response:
>
> http://gist.github.com/355456
>
> I intentionally provide only lazy-alter and no lazy-ref-set. The
> reason is that lazy-alter can be coded so that all the unwrapping and
> rewr
On 2010-04-04, at 11:15 AM, Per Vognsen wrote:
> Interesting question. Here's something I whipped up in response:
>
> http://gist.github.com/355456
>
> I intentionally provide only lazy-alter and no lazy-ref-set. The
> reason is that lazy-alter can be coded so that all the unwrapping and
> rewr
Interesting question. Here's something I whipped up in response:
http://gist.github.com/355456
I intentionally provide only lazy-alter and no lazy-ref-set. The
reason is that lazy-alter can be coded so that all the unwrapping and
rewrapping of delays can be abstracted away from the user-provided
Hi,
I have a situation where:
1) I have a lot of 'values' that are both expensive to compute and quite
large (they aren't all going to fit into memory) and most of which will not be
needed (this time, but maybe later)
2) I may have a need to update several of them them (in a transaction)
T
