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 > rewrapping of delays can be abstracted away from the user-provided > transformation function. A lazy-ref-set function would impose a much > stricter discipline on the user in order to maintain laziness. > > All the usual caveats about full laziness apply: beware of space > leaks, delayed side effects, etc.
That's really interesting. Thanks so much! Now I'll go think about it some more :-) Cheers, Bob > > -Per > > On Sun, Apr 4, 2010 at 9:35 PM, Bob Hutchison <hutch-li...@recursive.ca> > wrote: >> >> 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) >> >> The first case looks to be perfectly suited to delays. The second to refs. >> The values are going to be deftypes. >> >> So what I've come up with is a ref -> a delay -> a deftype. >> >> This is fine but it gets troublesome fast. >> >> The first time you try to get the deftype you have to write something like >> @@my-thing, and you keep writing that until the value is updated. The update >> will make the 'path' a ref -> a deftype (the delay is gone). This is bad I >> think because you now have to write @my-thing to get the value. >> >> The best that I've come up with is to update the ref with another delay, >> kind of like: (dosync (ref-set my-thing (delay my-updated-thing))) >> >> Is the the way to do it? Is there something better I could be doing? >> Something deref-able that I'm missing that is better suited than delay? Some >> kind of deref-all-the-way function? >> >> Thanks, >> Bob >> >> >> ---- >> Bob Hutchison >> Recursive Design Inc. >> http://www.recursive.ca/ >> weblog: http://xampl.com/so >> >> >> >> >> -- >> You received this message because you are subscribed to the Google >> Groups "Clojure" group. >> To post to this group, send email to clojure@googlegroups.com >> Note that posts from new members are moderated - please be patient with your >> first post. >> To unsubscribe from this group, send email to >> clojure+unsubscr...@googlegroups.com >> For more options, visit this group at >> http://groups.google.com/group/clojure?hl=en >> >> To unsubscribe, reply using "remove me" as the subject. >> > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en ---- Bob Hutchison Recursive Design Inc. http://www.recursive.ca/ weblog: http://xampl.com/so -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
