You're right. Here's a recursive example of what I was trying to do
with promise/deliver:
http://gist.github.com/284957
And with delay/force:
http://gist.github.com/284972
Nice comparison, thanks for sharing.
I suppose the one thing I like about promise/deliver is that
promises can be "watched" making it perhaps more extensible? Anyone
can get just attempt to deref the value inside a future to "watch
it". With delay/force it's harder to add new functionality without
mucking directly with the code. Or is there a better way to handle
this that I haven't thought of?
Nope, you're right about the advantages — futures (being essentially
control abstractions for tasks running on threads) are richer objects.
Delays have downsides: for example, just printing a delay will cause
its value to be computed. And of course using promises and futures
introduces parallelism into your code, which is sometimes desirable.
I see a kind of analogy — futures : delays :: refs : vars or atoms.
Both futures and refs hide a lot of functionality under the hood
(threads and synchronization for futures, the STM for refs), whilst
delays and the other state approaches are more applicable for local or
non-concurrent situations. Delaying computation with delay feels like
local accumulation using an atom, whilst computation with promises and
futures feels like distributing state operations with refs.
Thanks for the insights Richard.
Thanks for the discussion!
--
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
