Re: Reduce vs. Comp

I agree. I guess I was specifically thinking of a list of functions where the length of the list, and the functions themselves, are defined at run-time. Which would lead to some nasty code using the threading macros. (Unless someone has an example of this not being the case) On Wednesday, May

Re: Reduce vs. Comp

Reduce is indeed a swiss-army knife for functional programming over sequences. Of course, in this particular case (i.e., apply a sequence of functions in order to an initial value), Clojure's threading operators are the idiomatic way to go. (->> 6 (+ 12) (* -1)) Cheers, ~Gary -- You re

Re: Reduce vs. Comp

If you read the source for comp, you'll find that anything more than 3 args gets turned into something like reduce anyways: (defn comp "Takes a set of functions and returns a fn that is the composition of those fns. The returned fn takes a variable number of args, applies the rightmost of f

Re: Reduce vs. Comp

Hi, Mike Fikes wrote: > In fact, section 5 of that document defines comp as a reduce > involving the identify function in some way. (Now, I want to re-read > this paper, but translated into Clojure.) Here's one definition of comp in terms of reduce: (defn comp [& fs] (reduce (fn [result f]

Re: Reduce vs. Comp

I agree with the "re-implementing" comp sentiment. It reminds me of *A tutorial on the universality and expressiveness of fold *where, essentially lots of standard functions can be defined in terms of reduce which could be considered "primitive." In fac

Reduce vs. Comp

What is the difference between: (reduce #(%2 %) 6 [(partial + 12) (partial * -1)]) and ((apply comp [(partial * -1) (partial + 12)]) 6) Using reduce *looks* nicer to me, but I feel like I'm re-implementing comp. Their performance is also the same (go inlining!). -- You received this message