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 the false illusion that the user is dealing with a uniform abstraction when the semantics are really very different. Certainly lazy vs non-lazy semantics are pragmatically very different in a language like Clojure and the difference shouldn't be swept under the rug.
-Per On Mon, Apr 5, 2010 at 1:34 AM, Bob Hutchison <hutch-li...@recursive.ca> wrote: > > 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. > > Okay, I've had a closer look at what you've done. Thanks again. > > I don't need the delay after the alter. This makes lazy-ref-set pretty easy > to use. So I defined that function and modified your lazy-alter > implementation. > > This is beginning to look like a single type that is the combination of a ref > wrapping a delay, and it seems to work. I can also do some interesting things > when the alter/ref-set happens. So this is getting even better. > > Still this isn't quite 'in the language'. The user has to know that it's a > lazy ref: the functions lazy-alter/lazy-ref-set have to be used rather than > alter/ref-set. This is unfortunate I think. So I tried using defmethod, along > the lines of the the contrib libraries generic.arithmetic and > generic.comparison. Anyway, I've managed to define methods for alter and > ref-set that will dispatch properly, and so only alter/ref-set are needed > (it's an illusion maybe, but useful) > > Anyway, looks like this'll work well. > > 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 -- 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
