Re: function creation, partial or #()
Sean, it sounds like you want (swap! some-a update-in [:k1 :k2] (fnil conj []) id) But that's based on some pretty limited context. On Friday, August 16, 2013, Sean Corfield wrote: On Fri, Aug 16, 2013 at 4:32 PM, Timothy Baldridge tbaldri...@gmail.comjavascript:; wrote: I'm just going to throw this out there, but I almost always consider using #() instead of (fn []) to be bad practice. I still use #() for anonymous single argument functions that are small, single forms, but I've started switching to (fn [..] ..) for anything even slightly more complex because, like you, I find having a named argument to be worth the extra typing, even if it is just a single letter, suggestive of the argument type. Today I found myself writing (fnil #(conj % id) []) a couple of times because (fnil (fn [v] (conj v id)) []) doesn't seem any clearer - but suggestions for nicer code are always welcome. It's part of (swap! some-atom update-in [:path :to :item] ...) if that helps :) Sean -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.comjavascript:; 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 javascript:; 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 javascript:;. 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: function creation, partial or #()
Gosh darn... yes, that is what I want. That must be the only combination of things I didn't try! Thank you. On Sat, Aug 17, 2013 at 4:18 AM, Jay Fields j...@jayfields.com wrote: Sean, it sounds like you want (swap! some-a update-in [:k1 :k2] (fnil conj []) id) But that's based on some pretty limited context. On Friday, August 16, 2013, Sean Corfield wrote: On Fri, Aug 16, 2013 at 4:32 PM, Timothy Baldridge tbaldri...@gmail.com wrote: I'm just going to throw this out there, but I almost always consider using #() instead of (fn []) to be bad practice. I still use #() for anonymous single argument functions that are small, single forms, but I've started switching to (fn [..] ..) for anything even slightly more complex because, like you, I find having a named argument to be worth the extra typing, even if it is just a single letter, suggestive of the argument type. Today I found myself writing (fnil #(conj % id) []) a couple of times because (fnil (fn [v] (conj v id)) []) doesn't seem any clearer - but suggestions for nicer code are always welcome. It's part of (swap! some-atom update-in [:path :to :item] ...) if that helps :) Sean -- -- 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. -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ Perfection is the enemy of the good. -- Gustave Flaubert, French realist novelist (1821-1880) -- -- 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: function creation, partial or #()
As a newbie I got confused in the first place looking at codebases where partial was used, like your colleague said, it's in the docs: Takes a function f and fewer than the normal arguments to f, and returns a fn that takes a variable number of additional args. When called, the returned function calls f with args + additional args. I much prefer the #(), (fn[]) is longer so it's a no-go ;) On Tue, Aug 13, 2013 at 1:47 PM, Jay Fields j...@jayfields.com wrote: (do-work (partial say-hello bob)) (do-work #(say-hello bob)) I'd been using partial (which I font-lock**), but a teammate recently pointed out that partial's documentation explicitly calls out the fact that the number of args to partial should be less than the number of args to f. In practice it's been working 'fine', but I can't help but wonder if I'm sacrificing something I'm not aware of (performance?) ** with a font-lock, using partial *displays* the same number of chars as the reader macro solution, and I find it more readable when everything is in the parenthesis. - http://blog.jayfields.com/2013/05/emacs-lisp-font-lock-for-clojures.html -- -- 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: function creation, partial or #()
On Friday, August 16, 2013 9:45:53 AM UTC+2, Antonio Terreno wrote: I much prefer the #(), (fn[]) is longer so it's a no-go ;) fn has the huge advantage of taking an (optional) name, which will show up in stack traces. Just my 2ct Stefan -- -- 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: function creation, partial or #()
I will also note that any lamdba of more than one (_maybe_ two) args _must_, for me, be in the `(fn […] …)` form. Not only does it have the advantage of taking the function name, but it also is much easier to read what it's doing when I can explicitly name it's inputs. On Fri, Aug 16, 2013 at 7:37 AM, Stefan Kamphausen ska2...@gmail.com wrote: On Friday, August 16, 2013 9:45:53 AM UTC+2, Antonio Terreno wrote: I much prefer the #(), (fn[]) is longer so it's a no-go ;) fn has the huge advantage of taking an (optional) name, which will show up in stack traces. Just my 2ct Stefan -- -- 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: function creation, partial or #()
On Tue, Aug 13, 2013 at 1:50 PM, John D. Hume duelin.mark...@gmail.com wrote: Though in some cases the performance impact could be significant, my concern is readability. My understanding of the concept of partial function application is that it's about supplying some but not all of the arguments. So when I see `partial` in code, I expect more arguments to be supplied later, which is confusing when that's not the case. (Obviously context can make it easy to see that there will be no more arguments, but often that context is not present.) +1. Using partial to convert a unary func into a nullary func when #() is available strikes me as malpractice. Suppose you were to come across something like this in legacy code: (do-work (partial say-hello bob)) For me, the natural inference would be that say-hello must want at least one more arg (otherwise why partial?), so do-work must be feeding some arg to the result of (partial say-hello bob), like adding Don't worry, we're not watching you, in case the NSA owns do-work. Execution efficiency aside, downstream programmer confusion due to implied semantics also has a cost. -Gregg -- -- 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: function creation, partial or #()
I'm just going to throw this out there, but I almost always consider using #() instead of (fn []) to be bad practice. Like all syntactic sugar, it has its place, but I reach for fn more often then not, because it allows me to name the arguments and track in my mind the data with which I am working. % means nothing to me, (fn [person]) at least gives me, as the reader of your code, some context to go on when trying to parse what you've written. So I see it as a few less characters, at the expense of harder to understand code. Timothy On Fri, Aug 16, 2013 at 1:49 PM, Gregg Reynolds d...@mobileink.com wrote: On Tue, Aug 13, 2013 at 1:50 PM, John D. Hume duelin.mark...@gmail.com wrote: Though in some cases the performance impact could be significant, my concern is readability. My understanding of the concept of partial function application is that it's about supplying some but not all of the arguments. So when I see `partial` in code, I expect more arguments to be supplied later, which is confusing when that's not the case. (Obviously context can make it easy to see that there will be no more arguments, but often that context is not present.) +1. Using partial to convert a unary func into a nullary func when #() is available strikes me as malpractice. Suppose you were to come across something like this in legacy code: (do-work (partial say-hello bob)) For me, the natural inference would be that say-hello must want at least one more arg (otherwise why partial?), so do-work must be feeding some arg to the result of (partial say-hello bob), like adding Don't worry, we're not watching you, in case the NSA owns do-work. Execution efficiency aside, downstream programmer confusion due to implied semantics also has a cost. -Gregg -- -- 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. -- “One of the main causes of the fall of the Roman Empire was that–lacking zero–they had no way to indicate successful termination of their C programs.” (Robert Firth) -- -- 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: function creation, partial or #()
My two cents: The way I see it, the use of #( ... % ...) is analogous to the usage of the word it in English: only use it when it is obvious beyond a shadow of a doubt what it means. Think about how clunky English would be without the word it. On Fri, Aug 16, 2013 at 4:32 PM, Timothy Baldridge tbaldri...@gmail.comwrote: I'm just going to throw this out there, but I almost always consider using #() instead of (fn []) to be bad practice. Like all syntactic sugar, it has its place, but I reach for fn more often then not, because it allows me to name the arguments and track in my mind the data with which I am working. % means nothing to me, (fn [person]) at least gives me, as the reader of your code, some context to go on when trying to parse what you've written. So I see it as a few less characters, at the expense of harder to understand code. Timothy On Fri, Aug 16, 2013 at 1:49 PM, Gregg Reynolds d...@mobileink.com wrote: On Tue, Aug 13, 2013 at 1:50 PM, John D. Hume duelin.mark...@gmail.com wrote: Though in some cases the performance impact could be significant, my concern is readability. My understanding of the concept of partial function application is that it's about supplying some but not all of the arguments. So when I see `partial` in code, I expect more arguments to be supplied later, which is confusing when that's not the case. (Obviously context can make it easy to see that there will be no more arguments, but often that context is not present.) +1. Using partial to convert a unary func into a nullary func when #() is available strikes me as malpractice. Suppose you were to come across something like this in legacy code: (do-work (partial say-hello bob)) For me, the natural inference would be that say-hello must want at least one more arg (otherwise why partial?), so do-work must be feeding some arg to the result of (partial say-hello bob), like adding Don't worry, we're not watching you, in case the NSA owns do-work. Execution efficiency aside, downstream programmer confusion due to implied semantics also has a cost. -Gregg -- -- 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. -- “One of the main causes of the fall of the Roman Empire was that–lacking zero–they had no way to indicate successful termination of their C programs.” (Robert Firth) -- -- 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: function creation, partial or #()
On Fri, Aug 16, 2013 at 4:32 PM, Timothy Baldridge tbaldri...@gmail.com wrote: I'm just going to throw this out there, but I almost always consider using #() instead of (fn []) to be bad practice. I still use #() for anonymous single argument functions that are small, single forms, but I've started switching to (fn [..] ..) for anything even slightly more complex because, like you, I find having a named argument to be worth the extra typing, even if it is just a single letter, suggestive of the argument type. Today I found myself writing (fnil #(conj % id) []) a couple of times because (fnil (fn [v] (conj v id)) []) doesn't seem any clearer - but suggestions for nicer code are always welcome. It's part of (swap! some-atom update-in [:path :to :item] ...) if that helps :) Sean -- -- 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: function creation, partial or #()
On Fri, Aug 16, 2013 at 9:49 PM, Gregg Reynolds d...@mobileink.com wrote: On Tue, Aug 13, 2013 at 1:50 PM, John D. Hume duelin.mark...@gmail.com wrote: Though in some cases the performance impact could be significant, my concern is readability. My understanding of the concept of partial function application is that it's about supplying some but not all of the arguments. So when I see `partial` in code, I expect more arguments to be supplied later, which is confusing when that's not the case. (Obviously context can make it easy to see that there will be no more arguments, but often that context is not present.) +1. Using partial to convert a unary func into a nullary func when #() is available strikes me as malpractice. Suppose you were to come across something like this in legacy code: (do-work (partial say-hello bob)) For me, the natural inference would be that say-hello must want at least one more arg (otherwise why partial?), so do-work must be feeding some arg to the result of (partial say-hello bob), like adding Don't worry, we're not watching you, in case the NSA owns do-work. Execution efficiency aside, downstream programmer confusion due to implied semantics also has a cost. -Gregg I agree w/ John and Gregg, though I don't think I'd sue you for malpractice ;) partial means something and using it this way gives it a different meaning, even if it happens to solve the problem at hand. -- -- 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: function creation, partial or #()
(let [params (map (fn [_] (gensym fnp-)) (range n))] (repeatedly n #(gensym fnp-)) Best, Stefan -- -- 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: function creation, partial or #()
So I'm new to Clojure, and have been working through how to make Clojure code performant (i.e. what approaches are faster than others, how to profile, etc) by writing a (embarrassingly) simple ray-tracer. In a ray tracer there is a tight loop that runs per pixel, where you determine which of a list of object in the scene intersects with the ray for that pixel, and which is closest. At one point I was using partial as part of that logic. Changing partial to #() made the rendering time for a specific scene go down from 4.7s to 4.1s. #() is ugly though, and partial, as people has said, is more readable, because it speaks more to how that bit of code is going to be used. So I wrote the following macro: (defmacro partialn [n f args] (let [params (map (fn [_] (gensym fnp-)) (range n))] `(fn [~@params] (~f ~@args ~@params This is just a first cut and I'm sure there are rough edges, but you get the idea: we're using a macro to hide the creation of a 'static' anonymous function instead of writing it ourselves. When using this in my code in place of #(), the performance result is essentially identical. Apologies in advance if I've missed something obvious here, but is this something other people are interested in? Would this be useful in core? As far as I can tell it's something that is-- if you know the number of args you expect-- a strict upgrade to partial, though I'm willing to plead ignorance here. You could even re-write partial so supported both signatures (f args) and (f n args), though I'm not sure if that's idiomatic. Below is the specific data from bench. Note that these benchmarks aren't particularly scientific, they've all been running on a 2009MBP, from the REPL, with a :reload-all in between each run to swap code around. Each of these calls was essentially (map (partial f x) list-of-ys) - (f x y), so one arg passed on creation and one at runtime. The laptop was at the very least left alone while they were running, so any variance wasn't explicitly introduced by me. ; for (partial ..) Evaluation count : 60 in 60 samples of 1 calls. Execution time mean : 4.788510 sec Execution time std-deviation : 39.595196 ms Execution time lower quantile : 4.744957 sec ( 2.5%) Execution time upper quantile : 4.884646 sec (97.5%) Overhead used : 18.475768 ns Found 3 outliers in 60 samples (5. %) low-severe 1 (1.6667 %) low-mild 2 (3. %) Variance from outliers : 1.6389 % Variance is slightly inflated by outliers ; for #(..) Evaluation count : 60 in 60 samples of 1 calls. Execution time mean : 4.106831 sec Execution time std-deviation : 54.371302 ms Execution time lower quantile : 4.010274 sec ( 2.5%) Execution time upper quantile : 4.191842 sec (97.5%) Overhead used : 18.475768 ns Found 1 outliers in 60 samples (1.6667 %) low-severe 1 (1.6667 %) ; for (partialn 1 ..) Evaluation count : 60 in 60 samples of 1 calls. Execution time mean : 4.200536 sec Execution time std-deviation : 56.566857 ms Execution time lower quantile : 4.104481 sec ( 2.5%) Execution time upper quantile : 4.304463 sec (97.5%) Overhead used : 18.475768 ns Found 2 outliers in 60 samples (3. %) low-severe 1 (1.6667 %) low-mild 1 (1.6667 %) Variance from outliers : 1.6389 % Variance is slightly inflated by outliers On Wednesday, 14 August 2013 06:50:43 UTC+12, John Hume wrote: Though in some cases the performance impact could be significant, my concern is readability. My understanding of the concept of partial function application is that it's about supplying some but not all of the arguments. So when I see `partial` in code, I expect more arguments to be supplied later, which is confusing when that's not the case. (Obviously context can make it easy to see that there will be no more arguments, but often that context is not present.) On Tue, Aug 13, 2013 at 7:47 AM, Jay Fields j...@jayfields.comjavascript: wrote: Say you have a simple function: (defn do-work [f] (f)) When you want to call do-work you need a function, let's pretend we want to use this function: (defn say-hello [n] (println hello n)) Which of the following solutions do you prefer? (do-work (partial say-hello bob)) (do-work #(say-hello bob)) I'd been using partial (which I font-lock**), but a teammate recently pointed out that partial's documentation explicitly calls out the fact that the number of args to partial should be less than the number of args to f. In practice it's been working 'fine', but I can't help but wonder if I'm sacrificing something I'm not aware of (performance?) ** with a font-lock, using partial *displays* the same number of chars as the reader macro solution, and I find it more readable when everything is in the parenthesis. - http://blog.jayfields.com/2013/05/emacs-lisp-font-lock-for-clojures.html -- -- You
function creation, partial or #()
Say you have a simple function: (defn do-work [f] (f)) When you want to call do-work you need a function, let's pretend we want to use this function: (defn say-hello [n] (println hello n)) Which of the following solutions do you prefer? (do-work (partial say-hello bob)) (do-work #(say-hello bob)) I'd been using partial (which I font-lock**), but a teammate recently pointed out that partial's documentation explicitly calls out the fact that the number of args to partial should be less than the number of args to f. In practice it's been working 'fine', but I can't help but wonder if I'm sacrificing something I'm not aware of (performance?) ** with a font-lock, using partial *displays* the same number of chars as the reader macro solution, and I find it more readable when everything is in the parenthesis. - http://blog.jayfields.com/2013/05/emacs-lisp-font-lock-for-clojures.html -- -- 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: function creation, partial or #()
On 13/08/13 13:47, Jay Fields wrote: Say you have a simple function: (defn do-work [f] (f)) When you want to call do-work you need a function, let's pretend we want to use this function: (defn say-hello [n] (println hello n)) Which of the following solutions do you prefer? (do-work (partial say-hello bob)) (do-work #(say-hello bob)) I'd been using partial (which I font-lock**), but a teammate recently pointed out that partial's documentation explicitly calls out the fact that the number of args to partial should be less than the number of args to f. In practice it's been working 'fine', but I can't help but wonder if I'm sacrificing something I'm not aware of (performance?) ** with a font-lock, using partial *displays* the same number of chars as the reader macro solution, and I find it more readable when everything is in the parenthesis. - http://blog.jayfields.com/2013/05/emacs-lisp-font-lock-for-clojures.html since 'partial' 'comp' will give you back a function with varargs, it might be a tiny bit faster if you use #()... 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: function creation, partial or #()
Hi, Partial calls apply, so it's not as performant as #(..). That can make quite the difference depending on where it's used. All instances of partial were removed recently in carmine/nippy and that resulted in quite a performance improvement. On Tuesday, August 13, 2013 2:47:01 PM UTC+2, Jay Fields wrote: Say you have a simple function: (defn do-work [f] (f)) When you want to call do-work you need a function, let's pretend we want to use this function: (defn say-hello [n] (println hello n)) Which of the following solutions do you prefer? (do-work (partial say-hello bob)) (do-work #(say-hello bob)) I'd been using partial (which I font-lock**), but a teammate recently pointed out that partial's documentation explicitly calls out the fact that the number of args to partial should be less than the number of args to f. In practice it's been working 'fine', but I can't help but wonder if I'm sacrificing something I'm not aware of (performance?) ** with a font-lock, using partial *displays* the same number of chars as the reader macro solution, and I find it more readable when everything is in the parenthesis. - http://blog.jayfields.com/2013/05/emacs-lisp-font-lock-for-clojures.html -- -- 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: function creation, partial or #()
On Tue, Aug 13, 2013 at 8:47 AM, Jay Fields j...@jayfields.com wrote: Say you have a simple function: (defn do-work [f] (f)) When you want to call do-work you need a function, let's pretend we want to use this function: (defn say-hello [n] (println hello n)) Which of the following solutions do you prefer? (do-work (partial say-hello bob)) (do-work #(say-hello bob)) I'd been using partial (which I font-lock**), but a teammate recently pointed out that partial's documentation explicitly calls out the fact that the number of args to partial should be less than the number of args to f. In practice it's been working 'fine', but I can't help but wonder if I'm sacrificing something I'm not aware of (performance?) It depends. I endeavor to use `partial` whenever what I'm doing is fixing leading arguments. I think it reads better. Whenever I have to fall back to to the reader macro it is always because the args were ordered poorly for my particular use. I usually get frustrated at the library author at this point, and then quickly realize what an idiot I'm being and move on. I haven't had any situations yet that required deep optimization and I'm a firm believer in premature optimization being the root of all evil so for the entirety of my career in clojure I've only ever optimized for readability. I'll get to that next level soon enough, I'm sure. -- In Christ, Timmy V. http://blog.twonegatives.com/ http://five.sentenc.es/ -- Spend less time on mail -- -- 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: function creation, partial or #()
Though in some cases the performance impact could be significant, my concern is readability. My understanding of the concept of partial function application is that it's about supplying some but not all of the arguments. So when I see `partial` in code, I expect more arguments to be supplied later, which is confusing when that's not the case. (Obviously context can make it easy to see that there will be no more arguments, but often that context is not present.) On Tue, Aug 13, 2013 at 7:47 AM, Jay Fields j...@jayfields.com wrote: Say you have a simple function: (defn do-work [f] (f)) When you want to call do-work you need a function, let's pretend we want to use this function: (defn say-hello [n] (println hello n)) Which of the following solutions do you prefer? (do-work (partial say-hello bob)) (do-work #(say-hello bob)) I'd been using partial (which I font-lock**), but a teammate recently pointed out that partial's documentation explicitly calls out the fact that the number of args to partial should be less than the number of args to f. In practice it's been working 'fine', but I can't help but wonder if I'm sacrificing something I'm not aware of (performance?) ** with a font-lock, using partial *displays* the same number of chars as the reader macro solution, and I find it more readable when everything is in the parenthesis. - http://blog.jayfields.com/2013/05/emacs-lisp-font-lock-for-clojures.html -- -- 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. -- http://elhumidor.blogspot.com/ -- -- 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.
