I've used try-let (link below) for this, it's worked great!
https://github.com/rufoa/try-let
--
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
How come this is so debated, but normal variadic functions are not? Is it
only because there's nothing equivalent to apply for kwarg functions? Would
it really be such a huge addition to clojure.core to add a simple mapply
function, especially given that the core API have kwarg functions? (this
The REPL takes some effort if you're not used to it, but stick with it and
you shall be greatly rewarded!
Since it's such an interactive workflow, I feel that it helps to view
someone else use it. There's a great intro to Clojure video by Chas Emerick
where he develops a small web application,
I don't see how the macro version would offer any performance benefits - in
both cases, x is evaluated once and pred is called once. Am I missing
something?
Den fredagen den 24:e oktober 2014 kl. 15:47:50 UTC+2 skrev Fluid Dynamics:
>
> (defn if-its [pred x]
> (if (pred x) x))
>
> => (if-its e
er this would be an
> improvement performance-wise in any given scenario would need to be
> determined by benchmarking).
>
>
> On 2 September 2014 00:54, Marcus Magnusson > wrote:
> > Forget about sleep, there's work to be done! I realized that the
> drawback
e* (synced-memoize calc-value)]
> (fn [cache key]
> (if (contains? @cache key)
> (@cache key)
> (swap! cache assoc key (calc-value* key))
>
>
>
> Den måndagen den 1:e september 2014 kl. 22:35:56 UTC+2 skrev Marcus
> Magnusson:
>>
>> I reckon i
Huh, I gave it some more thought - of course, the reason why memoize won't
help us here is that there is no synchronization between simultaneous
invocations with the same set of arguments. This is typically not a problem
if the underlying function is fast, but in our case it would be neat with
I reckon if that worked, there would be no need for memoize anyway, but I
don't think swap! will allow for it. I'm far from an expert on swap! or
atoms, but several swap!s may be run simultaneously on a single atom (and
swap! may re-run the swapping function if the atom has been changed since
t
*
> should always return the same value for the same key, at worst you'll just
> end up swapping the same value in unnecessarily. I'd need to think a bit
> about the implications of using a memoised function in an atom update to
> convince myself, but it's a neat idea
How about something like this? You can still keep your cache as an atom
that you can pass around, and you avoid unnecessary recomputation through
memoize:
(def cache (atom {}))
(def lookup
(let [calc-value* (memoize calc-value)]
(fn [cache k]
(when-not (contains? @cache k)
(
I remember this talk to be very informative, I'm sure you'll find it useful:
http://www.infoq.com/presentations/Clojure-Namespaces-Vars-Symbols
Den lördagen den 10:e augusti 2013 kl. 00:21:02 UTC+2 skrev Jace Bennett:
>
> Out of curiousity, where do the defs go? Could one iterate over all the
> v
This article might be of interest:
http://clojurefun.wordpress.com/2012/09/03/ironclad-steam-legions-clojure-game-development-battle-report/
I haven't had much experience with game development in Clojure myself,
although one of the first real projects I made with Clojure was a simple
Tetris cl
12 matches
Mail list logo
