Re: Any alternatives for these two ugly patterns?
(merge {:attr something} obj)
--
--
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 unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: Any alternatives for these two ugly patterns?
Sorry, that's just another suggestion for the first pattern.
For the second, I would use:
(cond- obj (some-test obj) some-transformation)
On Sunday, May 26, 2013 12:05:49 PM UTC+2, dmirylenka wrote:
(merge {:attr something} obj)
--
--
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 unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Any alternatives for these two ugly patterns?
There are two patterns I find in my code that I'm still unhappy with but I don't know how to clean up. The first is: (if (:attr obj) obj (assoc obj :attr something)) I'm basically saying, give this hash-map an attribute if it doesn't already have it. And just return the thing with an attribute, regardless if I had to add it or not. This version is ugly because it repeats obj three times. I could write my own macro to de-duplicate it, but I avoid doing that when I can because there's usually a better built-in solution that I just don't know about yet. The second is like it: (if (some-test obj) obj (some-transformation obj)) In this one, I just want to return the object, but maybe transform it first. But the reference to obj happens three times! Still feels like it could be cleaned up. Any thoughts on how to clean these up? -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Any alternatives for these two ugly patterns?
On 25/05/13 12:24, Steven Degutis wrote: The first is: (if (:attr obj) obj (assoc obj :attr something)) I'm basically saying, give this hash-map an attribute if it doesn't already have it. And just return the thing with an attribute, regardless if I had to add it or not. (if (contains? obj :attr) obj (assoc obj :attr something)) it's more evident now, but you still mention obj 3 times... your second example seems just fine to me...if you have to test for something, well, you have to test for something!!! Jim -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Any alternatives for these two ugly patterns?
may I see the macro for the latter, if you decide to go that way ? thx On Sat, May 25, 2013 at 2:24 PM, Steven Degutis sbdegu...@gmail.com wrote: There are two patterns I find in my code that I'm still unhappy with but I don't know how to clean up. The first is: (if (:attr obj) obj (assoc obj :attr something)) I'm basically saying, give this hash-map an attribute if it doesn't already have it. And just return the thing with an attribute, regardless if I had to add it or not. This version is ugly because it repeats obj three times. I could write my own macro to de-duplicate it, but I avoid doing that when I can because there's usually a better built-in solution that I just don't know about yet. The second is like it: (if (some-test obj) obj (some-transformation obj)) In this one, I just want to return the object, but maybe transform it first. But the reference to obj happens three times! Still feels like it could be cleaned up. Any thoughts on how to clean these up? -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Any alternatives for these two ugly patterns?
no need for macros... :) (definline safe-assoc [m k v] `(if (contains? ~m ~k) ~m (assoc ~m ~k ~v))) (definline pred-transform [obj pred tf] `(if ~(pred obj) ~obj ~(tf obj))) Jim On 25/05/13 12:44, atkaaz wrote: may I see the macro for the latter, if you decide to go that way ? thx On Sat, May 25, 2013 at 2:24 PM, Steven Degutis sbdegu...@gmail.com mailto:sbdegu...@gmail.com wrote: There are two patterns I find in my code that I'm still unhappy with but I don't know how to clean up. The first is: (if (:attr obj) obj (assoc obj :attr something)) I'm basically saying, give this hash-map an attribute if it doesn't already have it. And just return the thing with an attribute, regardless if I had to add it or not. This version is ugly because it repeats obj three times. I could write my own macro to de-duplicate it, but I avoid doing that when I can because there's usually a better built-in solution that I just don't know about yet. The second is like it: (if (some-test obj) obj (some-transformation obj)) In this one, I just want to return the object, but maybe transform it first. But the reference to obj happens three times! Still feels like it could be cleaned up. Any thoughts on how to clean these up? -- -- 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 mailto: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 mailto:clojure%2bunsubscr...@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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com mailto:clojure%2bunsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Any alternatives for these two ugly patterns?
didn't know about definline, thanks Jim! On Sat, May 25, 2013 at 2:51 PM, Jim - FooBar(); jimpil1...@gmail.comwrote: no need for macros... :) (definline safe-assoc [m k v] `(if (contains? ~m ~k) ~m (assoc ~m ~k ~v))) (definline pred-transform [obj pred tf] `(if ~(pred obj) ~obj ~(tf obj))) Jim On 25/05/13 12:44, atkaaz wrote: may I see the macro for the latter, if you decide to go that way ? thx On Sat, May 25, 2013 at 2:24 PM, Steven Degutis sbdegu...@gmail.comwrote: There are two patterns I find in my code that I'm still unhappy with but I don't know how to clean up. The first is: (if (:attr obj) obj (assoc obj :attr something)) I'm basically saying, give this hash-map an attribute if it doesn't already have it. And just return the thing with an attribute, regardless if I had to add it or not. This version is ugly because it repeats obj three times. I could write my own macro to de-duplicate it, but I avoid doing that when I can because there's usually a better built-in solution that I just don't know about yet. The second is like it: (if (some-test obj) obj (some-transformation obj)) In this one, I just want to return the object, but maybe transform it first. But the reference to obj happens three times! Still feels like it could be cleaned up. Any thoughts on how to clean these up? -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Any alternatives for these two ugly patterns?
just wondering if obj is a form does it get evaluated twice? On Sat, May 25, 2013 at 2:51 PM, Jim - FooBar(); jimpil1...@gmail.comwrote: no need for macros... :) (definline safe-assoc [m k v] `(if (contains? ~m ~k) ~m (assoc ~m ~k ~v))) (definline pred-transform [obj pred tf] `(if ~(pred obj) ~obj ~(tf obj))) Jim On 25/05/13 12:44, atkaaz wrote: may I see the macro for the latter, if you decide to go that way ? thx On Sat, May 25, 2013 at 2:24 PM, Steven Degutis sbdegu...@gmail.comwrote: There are two patterns I find in my code that I'm still unhappy with but I don't know how to clean up. The first is: (if (:attr obj) obj (assoc obj :attr something)) I'm basically saying, give this hash-map an attribute if it doesn't already have it. And just return the thing with an attribute, regardless if I had to add it or not. This version is ugly because it repeats obj three times. I could write my own macro to de-duplicate it, but I avoid doing that when I can because there's usually a better built-in solution that I just don't know about yet. The second is like it: (if (some-test obj) obj (some-transformation obj)) In this one, I just want to return the object, but maybe transform it first. But the reference to obj happens three times! Still feels like it could be cleaned up. Any thoughts on how to clean these up? -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Any alternatives for these two ugly patterns?
Shouldn't it be like: (definline pred-transform [obj pred tf] `(if (~pred ~obj) ~obj (~tf ~obj))) = (pred-transform 1 #(not (nil? %)) println) 1 = (pred-transform 1 nil? println) 1 nil On Sat, May 25, 2013 at 2:55 PM, atkaaz atk...@gmail.com wrote: just wondering if obj is a form does it get evaluated twice? On Sat, May 25, 2013 at 2:51 PM, Jim - FooBar(); jimpil1...@gmail.comwrote: no need for macros... :) (definline safe-assoc [m k v] `(if (contains? ~m ~k) ~m (assoc ~m ~k ~v))) (definline pred-transform [obj pred tf] `(if ~(pred obj) ~obj ~(tf obj))) Jim On 25/05/13 12:44, atkaaz wrote: may I see the macro for the latter, if you decide to go that way ? thx On Sat, May 25, 2013 at 2:24 PM, Steven Degutis sbdegu...@gmail.comwrote: There are two patterns I find in my code that I'm still unhappy with but I don't know how to clean up. The first is: (if (:attr obj) obj (assoc obj :attr something)) I'm basically saying, give this hash-map an attribute if it doesn't already have it. And just return the thing with an attribute, regardless if I had to add it or not. This version is ugly because it repeats obj three times. I could write my own macro to de-duplicate it, but I avoid doing that when I can because there's usually a better built-in solution that I just don't know about yet. The second is like it: (if (some-test obj) obj (some-transformation obj)) In this one, I just want to return the object, but maybe transform it first. But the reference to obj happens three times! Still feels like it could be cleaned up. Any thoughts on how to clean these up? -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Any alternatives for these two ugly patterns?
in which case it does get evaluated twice if form: = (pred-transform (println 1) #(not (nil? %)) #(println % .)) 1 1 nil . nil = (pred-transform (println 1) nil? #(println % .)) 1 1 nil so maybe a let + gensym would be in order? On Sat, May 25, 2013 at 3:04 PM, atkaaz atk...@gmail.com wrote: Shouldn't it be like: (definline pred-transform [obj pred tf] `(if (~pred ~obj) ~obj (~tf ~obj))) = (pred-transform 1 #(not (nil? %)) println) 1 = (pred-transform 1 nil? println) 1 nil On Sat, May 25, 2013 at 2:55 PM, atkaaz atk...@gmail.com wrote: just wondering if obj is a form does it get evaluated twice? On Sat, May 25, 2013 at 2:51 PM, Jim - FooBar(); jimpil1...@gmail.comwrote: no need for macros... :) (definline safe-assoc [m k v] `(if (contains? ~m ~k) ~m (assoc ~m ~k ~v))) (definline pred-transform [obj pred tf] `(if ~(pred obj) ~obj ~(tf obj))) Jim On 25/05/13 12:44, atkaaz wrote: may I see the macro for the latter, if you decide to go that way ? thx On Sat, May 25, 2013 at 2:24 PM, Steven Degutis sbdegu...@gmail.comwrote: There are two patterns I find in my code that I'm still unhappy with but I don't know how to clean up. The first is: (if (:attr obj) obj (assoc obj :attr something)) I'm basically saying, give this hash-map an attribute if it doesn't already have it. And just return the thing with an attribute, regardless if I had to add it or not. This version is ugly because it repeats obj three times. I could write my own macro to de-duplicate it, but I avoid doing that when I can because there's usually a better built-in solution that I just don't know about yet. The second is like it: (if (some-test obj) obj (some-transformation obj)) In this one, I just want to return the object, but maybe transform it first. But the reference to obj happens three times! Still feels like it could be cleaned up. Any thoughts on how to clean these up? -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Any alternatives for these two ugly patterns?
like: = (definline pred-transform [obj pred tf] `(let [o# ~obj] (if (~pred o#) o# (~tf o# #'cgws.notcore/pred-transform = (pred-transform (println 1) nil? #(println % .)) 1 nil = (pred-transform (println 1) #(not (nil? %)) #(println % .)) 1 nil . nil On Sat, May 25, 2013 at 3:07 PM, atkaaz atk...@gmail.com wrote: in which case it does get evaluated twice if form: = (pred-transform (println 1) #(not (nil? %)) #(println % .)) 1 1 nil . nil = (pred-transform (println 1) nil? #(println % .)) 1 1 nil so maybe a let + gensym would be in order? On Sat, May 25, 2013 at 3:04 PM, atkaaz atk...@gmail.com wrote: Shouldn't it be like: (definline pred-transform [obj pred tf] `(if (~pred ~obj) ~obj (~tf ~obj))) = (pred-transform 1 #(not (nil? %)) println) 1 = (pred-transform 1 nil? println) 1 nil On Sat, May 25, 2013 at 2:55 PM, atkaaz atk...@gmail.com wrote: just wondering if obj is a form does it get evaluated twice? On Sat, May 25, 2013 at 2:51 PM, Jim - FooBar(); jimpil1...@gmail.comwrote: no need for macros... :) (definline safe-assoc [m k v] `(if (contains? ~m ~k) ~m (assoc ~m ~k ~v))) (definline pred-transform [obj pred tf] `(if ~(pred obj) ~obj ~(tf obj))) Jim On 25/05/13 12:44, atkaaz wrote: may I see the macro for the latter, if you decide to go that way ? thx On Sat, May 25, 2013 at 2:24 PM, Steven Degutis sbdegu...@gmail.comwrote: There are two patterns I find in my code that I'm still unhappy with but I don't know how to clean up. The first is: (if (:attr obj) obj (assoc obj :attr something)) I'm basically saying, give this hash-map an attribute if it doesn't already have it. And just return the thing with an attribute, regardless if I had to add it or not. This version is ugly because it repeats obj three times. I could write my own macro to de-duplicate it, but I avoid doing that when I can because there's usually a better built-in solution that I just don't know about yet. The second is like it: (if (some-test obj) obj (some-transformation obj)) In this one, I just want to return the object, but maybe transform it first. But the reference to obj happens three times! Still feels like it could be cleaned up. Any thoughts on how to clean these up? -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- 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 unsubscribe from
Re: Any alternatives for these two ugly patterns?
I wonder why the definline didn't act like a function? = (defn pred-transform [obj pred tf] (if (pred obj) obj (tf obj))) #'cgws.notcore/pred-transform = (pred-transform (println 1) #(not (nil? %)) #(println % .)) 1 nil . nil = (pred-transform (println 1) nil? #(println % .)) 1 nil = (fn? pred-transform) true = (definline pred-transform [obj pred tf] `(let [o# ~obj] (if (~pred o#) o# (~tf o# #'cgws.notcore/pred-transform = (fn? pred-transform) true On Sat, May 25, 2013 at 3:08 PM, atkaaz atk...@gmail.com wrote: like: = (definline pred-transform [obj pred tf] `(let [o# ~obj] (if (~pred o#) o# (~tf o# #'cgws.notcore/pred-transform = (pred-transform (println 1) nil? #(println % .)) 1 nil = (pred-transform (println 1) #(not (nil? %)) #(println % .)) 1 nil . nil On Sat, May 25, 2013 at 3:07 PM, atkaaz atk...@gmail.com wrote: in which case it does get evaluated twice if form: = (pred-transform (println 1) #(not (nil? %)) #(println % .)) 1 1 nil . nil = (pred-transform (println 1) nil? #(println % .)) 1 1 nil so maybe a let + gensym would be in order? On Sat, May 25, 2013 at 3:04 PM, atkaaz atk...@gmail.com wrote: Shouldn't it be like: (definline pred-transform [obj pred tf] `(if (~pred ~obj) ~obj (~tf ~obj))) = (pred-transform 1 #(not (nil? %)) println) 1 = (pred-transform 1 nil? println) 1 nil On Sat, May 25, 2013 at 2:55 PM, atkaaz atk...@gmail.com wrote: just wondering if obj is a form does it get evaluated twice? On Sat, May 25, 2013 at 2:51 PM, Jim - FooBar(); jimpil1...@gmail.com wrote: no need for macros... :) (definline safe-assoc [m k v] `(if (contains? ~m ~k) ~m (assoc ~m ~k ~v))) (definline pred-transform [obj pred tf] `(if ~(pred obj) ~obj ~(tf obj))) Jim On 25/05/13 12:44, atkaaz wrote: may I see the macro for the latter, if you decide to go that way ? thx On Sat, May 25, 2013 at 2:24 PM, Steven Degutis sbdegu...@gmail.comwrote: There are two patterns I find in my code that I'm still unhappy with but I don't know how to clean up. The first is: (if (:attr obj) obj (assoc obj :attr something)) I'm basically saying, give this hash-map an attribute if it doesn't already have it. And just return the thing with an attribute, regardless if I had to add it or not. This version is ugly because it repeats obj three times. I could write my own macro to de-duplicate it, but I avoid doing that when I can because there's usually a better built-in solution that I just don't know about yet. The second is like it: (if (some-test obj) obj (some-transformation obj)) In this one, I just want to return the object, but maybe transform it first. But the reference to obj happens three times! Still feels like it could be cleaned up. Any thoughts on how to clean these up? -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit
Re: Any alternatives for these two ugly patterns?
On Sat, May 25, 2013 at 3:16 PM, Steven Degutis sbdegu...@gmail.com wrote:
Also I just remembered, sometimes to solve the second one, I would do ((if
condition transformer identity) obj) but that feels ugly.
but the condition has to contain obj, so obj is referred twice ? otherwise
i kinda like it
On Sat, May 25, 2013 at 7:13 AM, Cedric Greevey cgree...@gmail.comwrote:
Seems to me that (merge {:attr something} obj) answers the OP's question,
mentions obj only once, and is short and pithy. OTOH it computes the
something every time, whether it's needed or not, so in cases where
something is expensive to compute (or has side effects that should only
happen if it winds up in the output!) then another method needs to be used.
On Sat, May 25, 2013 at 8:08 AM, atkaaz atk...@gmail.com wrote:
like:
= (definline pred-transform [obj pred tf]
`(let [o# ~obj]
(if (~pred o#) o#
(~tf o#
#'cgws.notcore/pred-transform
= (pred-transform (println 1) nil? #(println % .))
1
nil
= (pred-transform (println 1) #(not (nil? %)) #(println % .))
1
nil .
nil
On Sat, May 25, 2013 at 3:07 PM, atkaaz atk...@gmail.com wrote:
in which case it does get evaluated twice if form:
= (pred-transform (println 1) #(not (nil? %)) #(println % .))
1
1
nil .
nil
= (pred-transform (println 1) nil? #(println % .))
1
1
nil
so maybe a let + gensym would be in order?
On Sat, May 25, 2013 at 3:04 PM, atkaaz atk...@gmail.com wrote:
Shouldn't it be like:
(definline pred-transform [obj pred tf]
`(if (~pred ~obj) ~obj
(~tf ~obj)))
= (pred-transform 1 #(not (nil? %)) println)
1
= (pred-transform 1 nil? println)
1
nil
On Sat, May 25, 2013 at 2:55 PM, atkaaz atk...@gmail.com wrote:
just wondering if obj is a form does it get evaluated twice?
On Sat, May 25, 2013 at 2:51 PM, Jim - FooBar();
jimpil1...@gmail.com wrote:
no need for macros... :)
(definline safe-assoc [m k v]
`(if (contains? ~m ~k) ~m
(assoc ~m ~k ~v)))
(definline pred-transform [obj pred tf]
`(if ~(pred obj) ~obj
~(tf obj)))
Jim
On 25/05/13 12:44, atkaaz wrote:
may I see the macro for the latter, if you decide to go that way ?
thx
On Sat, May 25, 2013 at 2:24 PM, Steven Degutis sbdegu...@gmail.com
wrote:
There are two patterns I find in my code that I'm still unhappy
with but I don't know how to clean up.
The first is: (if (:attr obj) obj (assoc obj :attr something))
I'm basically saying, give this hash-map an attribute if it
doesn't already have it. And just return the thing with an attribute,
regardless if I had to add it or not.
This version is ugly because it repeats obj three times. I could
write my own macro to de-duplicate it, but I avoid doing that when I
can
because there's usually a better built-in solution that I just don't
know
about yet.
The second is like it: (if (some-test obj) obj
(some-transformation obj))
In this one, I just want to return the object, but maybe
transform it first. But the reference to obj happens three times! Still
feels like it could be cleaned up.
Any thoughts on how to clean these up?
--
--
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 unsubscribe from this group and stop receiving emails from it,
send an email to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
--
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 unsubscribe from this group and stop receiving emails from it,
send an email to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
--
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
Re: Any alternatives for these two ugly patterns?
(update-in obj [:attr] #(or %1 %2) something) (cond- obj (not (:attr obj)) (assoc :attr something)) -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Any alternatives for these two ugly patterns?
Seems like I almost want arbitrary or-like behavior, like only-sometimes-evaluation of a conditional form. I feel like this could have something to do with lazy sequences, since technically has the option of never getting evaluated. We could use map. Will test some things out in nrepl.el and return with interesting results if any. On Sat, May 25, 2013 at 7:52 AM, Matching Socks phill.w...@gmail.comwrote: (update-in obj [:attr] #(or %1 %2) something) (cond- obj (not (:attr obj)) (assoc :attr something)) -- -- 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 a topic in the Google Groups Clojure group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/clojure/1GFesvqspwk/unsubscribe?hl=en. To unsubscribe from this group and all its topics, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Any alternatives for these two ugly patterns?
so maybe a let + gensym would be in order? yes that is what you do to avoid double-evaluation...:) I was making a different point though, the fact that definline produces a first class fn which still expands like a macro. Jim -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Any alternatives for these two ugly patterns?
yep that was interesting thanks btw; it was a function that was acting like a macro, how odd On Sat, May 25, 2013 at 4:26 PM, Jim - FooBar(); jimpil1...@gmail.comwrote: so maybe a let + gensym would be in order? yes that is what you do to avoid double-evaluation...:) I was making a different point though, the fact that definline produces a first class fn which still expands like a macro. Jim -- -- 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+unsubscribe@**googlegroups.comclojure%2bunsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/**group/clojure?hl=enhttp://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscribe@**googlegroups.comclojure%2bunsubscr...@googlegroups.com . For more options, visit https://groups.google.com/**groups/opt_outhttps://groups.google.com/groups/opt_out . -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Any alternatives for these two ugly patterns?
Here's my solution to your problem. Let me know if it helps.
```
user (defn if-attr [-key obj missing]
(if-let [ret (get obj -key)] ret (assoc obj -key missing)))
#'user/if-attr
user (if-attr :abc {} missing-value)
{:abc missing-value}
user (if-attr :abc {:abc 123} missing-value)
123
user
```
25.05.2013, 22:29, atkaaz atk...@gmail.com:
yep that was interesting thanks btw; it was a function that was acting like
a macro, how odd
On Sat, May 25, 2013 at 4:26 PM, Jim - FooBar(); jimpil1...@gmail.com
wrote:
so maybe a let + gensym would be in order?
yes that is what you do to avoid double-evaluation...:) I was making a
different point though, the fact that definline produces a first class fn
which still expands like a macro.
Jim
--
--
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 unsubscribe from this group and stop receiving emails from it, send an
email to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
--
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 unsubscribe from this group and stop receiving emails from it, send an
email to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
--
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 unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: Any alternatives for these two ugly patterns?
I just realised you can also do this to get the same effect of pred-transform...This is the first time I'm using cond-! I'm starting to realise its usefuleness... :) (let [rpred (complement pred)] (cond- obj (pred obj) identity ;;if true return it untouched (rpred obj) tf)) ;;if false do the transformation Jim On 25/05/13 14:29, atkaaz wrote: yep that was interesting thanks btw; it was a function that was acting like a macro, how odd On Sat, May 25, 2013 at 4:26 PM, Jim - FooBar(); jimpil1...@gmail.com mailto:jimpil1...@gmail.com wrote: so maybe a let + gensym would be in order? yes that is what you do to avoid double-evaluation...:) I was making a different point though, the fact that definline produces a first class fn which still expands like a macro. Jim -- -- 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 mailto: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 mailto:clojure%2bunsubscr...@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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com mailto:clojure%2bunsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Any alternatives for these two ugly patterns?
Another solution, repeats itself slightly less: (assoc obj :key (or (:key obj) (something-else-with-side-effects-maybe?))) Not sure I like it much better than the first one. But I usually prefer not writing my own macros/functions when I can avoid it, so it has that plus. On Sat, May 25, 2013 at 8:50 AM, Jim - FooBar(); jimpil1...@gmail.comwrote: I just realised you can also do this to get the same effect of pred-transform...This is the first time I'm using cond-! I'm starting to realise its usefuleness... :) (let [rpred (complement pred)] (cond- obj (pred obj) identity ;;if true return it untouched (rpred obj) tf)) ;;if false do the transformation Jim On 25/05/13 14:29, atkaaz wrote: yep that was interesting thanks btw; it was a function that was acting like a macro, how odd On Sat, May 25, 2013 at 4:26 PM, Jim - FooBar(); jimpil1...@gmail.comwrote: so maybe a let + gensym would be in order? yes that is what you do to avoid double-evaluation...:) I was making a different point though, the fact that definline produces a first class fn which still expands like a macro. Jim -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- 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 a topic in the Google Groups Clojure group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/clojure/1GFesvqspwk/unsubscribe?hl=en. To unsubscribe from this group and all its topics, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
