Re: Memoize in the real world

2014-12-15 Thread Andy Dwelly
It looks very similar to the pattern I was trying to avoid in the first place. I've also got the problem of multiple threads (and its been pointed out that my original solution was not thread safe). In my experience bugs of an 'extremely rare but could conceivably happen' nature are the sort of

Re: Memoize in the real world

2014-12-15 Thread Sergey Didenko
As I understand this var approach is used for development purposes, so in theory it should not occur in production. I wonder though why someone would prefer it to atoms. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email

Re: Memoize in the real world

2014-12-13 Thread Sergey Didenko
Some people use vars for seldom changing things. What do you think about this VS atoms? For example: (declare ^:dynamic *server*) (defn get-possibly-unbound-var [v] (try (var-get v) (catch Exception e nil))) (defn start-server! [] (if (get-possibly-unbound-var *server*)

Re: Memoize in the real world

2014-12-10 Thread Andy Dwelly
Thanks to everyone for the responses. I was completely unaware of core.memoize although I think there is a very convincing case for delay; I certainly accept the thread safety problem with the existing code. Action this day on that one! I'm inclined to go down the @@ syntactic route, simply in

Re: Memoize in the real world

2014-12-10 Thread Gary Verhaegen
Although if you do not expect the config to change, you do not need to wrap the delay in an atom. The atom in Steven Yi's solution is only there to allow the combination of (delay) executing the operation strictly once but also (atom) allow for changing the underlying value (i.e. clear the cache).

Re: Memoize in the real world

2014-12-10 Thread Andy Dwelly
Understood. I was using a configuration example as a kind of shorthand for a larger set of problems - most of which are multithreaded and will be dealing with occasionally changing results. As usual, its a tricky area, but not as difficult as achieving the same result in some other

Memoize in the real world

2014-12-09 Thread Andy Dwelly
Looking through my recent work I see that a number of atoms, swap! and reset! calls have snuck into my work, usually when there's an expensive operation like reading and parsing a large file or connecting to a database. I find I'm doing things like (def conf (atom nil)) (defn config [] (if

Re: Memoize in the real world

2014-12-09 Thread Andrey Antukh
Hi! 2014-12-09 18:08 GMT+01:00 Andy Dwelly andydwe...@gmail.com: Looking through my recent work I see that a number of atoms, swap! and reset! calls have snuck into my work, usually when there's an expensive operation like reading and parsing a large file or connecting to a database. I find

Re: Memoize in the real world

2014-12-09 Thread David Powell
If you want to use memoize, then the clojure.core.memoize provides a more tunable version, which supports clearing the cache if required. https://github.com/clojure/core.memoize/blob/master/docs/Using.md -- You received this message because you are subscribed to the Google Groups Clojure group.

Re: Memoize in the real world

2014-12-09 Thread Steven Yi
Hi Andy, Just my two cents here, but I don't think memoize makes sense here myself due to this not being referentially transparent, and I think Andrey's comment on delays makes more sense to me. You could do something like this: (def conf (atom (delay (read-and-expensively-parse

Re: Memoize in the real world

2014-12-09 Thread Fluid Dynamics
On Tuesday, December 9, 2014 7:19:27 PM UTC-5, Steven Yi wrote: Hi Andy, Just my two cents here, but I don't think memoize makes sense here myself due to this not being referentially transparent, and I think Andrey's comment on delays makes more sense to me. You could do something like

Re: Memoize in the real world

2014-12-09 Thread Steven Yi
No reason really, just ended up writing it that way for the example. (Maybe subconsciously I didn't want to think about pointer pointers and wanted to break up the notation. :P) On Tue, Dec 9, 2014 at 11:18 PM, Fluid Dynamics a2093...@trbvm.com wrote: On Tuesday, December 9, 2014 7:19:27 PM