On Aug 17, 2009, at 1:27 AM, Meikel Brandmeyer wrote:
> Not in general. But as a rule of thumb: every fn/#()
> generates a class and hence everything using it:
> defn, comp, partial, letfn, thunk'ing in macros, ...
Thanks!
—
Daniel Lyons
--~--~-~--~~~---~--~~
Hi,
On Aug 17, 8:51 am, Daniel Lyons wrote:
> > Also this function generates two classes, while the
> > other two variants generate 6.
>
> Is there an easy way to tell how many classes a given function
> generates?
Not in general. But as a rule of thumb: every fn/#()
generates a class and he
On Aug 13, 2009, at 12:16 AM, Meikel Brandmeyer wrote:
> Also this function generates two classes, while the
> other two variants generate 6.
Is there an easy way to tell how many classes a given function
generates?
—
Daniel Lyons
--~--~-~--~~~---~--~~
You
On Aug 12, 2009, at 10:34 PM, Richard Newman wrote:
> This is the difference between 'conventional' and point-free style, by
> the way. Many people view point-free as being somehow more elegant,
> and I'm generally inclined to agree... apart from in cases like your
> example, where a ton of part
> Also this function generates two classes, while the
> other two variants generate 6.
Thank you for pointing this out! It -- surprisingly -- hadn't occurred
to me before that different approaches to writing the same code would
actually generate different sets of classes, possibly of very
d
Hi,
On Aug 13, 6:34 am, Richard Newman wrote:
> I find this much nicer than stacking parens:
>
> (defn clean-lines [x]
> (non-empty
> (trimmed-lines
> (read-lines x)))
There is also the nice -> macro.
(defn clean-lines
[x]
(-> x read-lines trimmed-li
Hi,
On Aug 13, 2:02 am, Sean Devlin wrote:
> A) Traditional definition
>
> (defn str->date-map
> [input-string]
> ((trans :month (comp dec :month))
> (apply hash-map (interleave
> [:month :day :year]
> (map parse-int (re-split input-string #"/")))
A point-free definition does not explicitly mention the values of the
space on which the function acts.
See http://www.haskell.org/haskellwiki/Pointfree.
> On Thu, Aug 13, 2009 at 12:34 AM, Richard Newman
> wrote:
> This is the difference between 'conventional' and point-free style, by
> th
On Thu, Aug 13, 2009 at 12:34 AM, Richard Newman wrote:
> This is the difference between 'conventional' and point-free style, by
> the way. Many people view point-free as being somehow more elegant,
> and I'm generally inclined to agree... apart from in cases like your
> example, where a ton of p
> Let me know what you all think!
In this case, A. I've definitely been known to use composition, but
only when the definition is simple and expressive: e.g.,
(def clean-lines (comp non-empty trimmed-lines read-lines))
I find this much nicer than stacking parens:
(defn clean-lines [x]
(no
I would also vote A, seems much more straight forward.
On Wed, Aug 12, 2009 at 8:02 PM, Sean Devlin wrote:
>
> Hello Clojurians,
> I've been experimenting with different coding styles, and I'm
> interested in the group's opinion. Which set of code is easiest to
> read?
>
> A) Traditional definit
> Let me know what you all think!
Just thought it worth a mention that another approach to composed
partials is to use a 'pipe' macro (similar to ->). There was a very
good thread about various implementations which I can't find anymore :
( FWIW I like your use of & as comp but $ for partial doe
The first one is still the most straightforward to me personally. I
feel there's no need to introduce function composition if there's no
immediate advantage. In this case, In Clojure's case, I'm guessing
function composition comes with some performance costs as well.
-Patrick
--~--~-~--~
Hello Clojurians,
I've been experimenting with different coding styles, and I'm
interested in the group's opinion. Which set of code is easiest to
read?
A) Traditional definition
(defn str->date-map
[input-string]
((trans :month (comp dec :month))
(apply hash-map (interleave
14 matches
Mail list logo
