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

Re: -> vs comp

The F# language does partial application through calling the function: if you don't supply enough arguments, they're partially applied. The |> syntax is for "backwards" (object-y) partial application: let f x y = ... let g = f 1 let h = 1 |> f The |> operator is built-in in F#, but in OCaml

Re: -> vs comp

I've been using & and p, respectively. On Oct 18, 2:21 pm, B Smith-Mannschott wrote: > On Sun, Oct 18, 2009 at 20:04, Stuart Halloway > > wrote: > > > I find the suite of ->, ->>, anonymous functions, partial, and comp > > sufficient for my needs, with each having its place. > > > My only grumb

Re: -> vs comp

On Sun, Oct 18, 2009 at 20:04, Stuart Halloway wrote: > > I find the suite of ->, ->>, anonymous functions, partial, and comp > sufficient for my needs, with each having its place. > > My only grumble is that "partial" is a lot of characters. I would love > a one-character alternative, if it coul

Re: -> vs comp

I find the suite of ->, ->>, anonymous functions, partial, and comp sufficient for my needs, with each having its place. My only grumble is that "partial" is a lot of characters. I would love a one-character alternative, if it could be reasonably intuitive. Stu > On Oct 16, 10:22 pm, Sean D

Re: -> vs comp

On Oct 16, 10:22 pm, Sean Devlin wrote: > In order to generate closures, every function should take parameters > first, and data at the end, so that they work well with partial. It's really hard to come up with a consistent practice that works well for all scenarios. Even clojure.core is incons

Re: -> vs comp

Kinda off topic. I didn't realize ->> has been introduced. Is there a list of new forms that's been introduced since 1.0? Thanks On Sat, Oct 17, 2009 at 9:17 AM, Laurent PETIT wrote: > > > 2009/10/17 James Reeves >> >> On Oct 17, 4:55 am, samppi wrote: >> > Personally, I can go either way—I j

Re: -> vs comp

Okay, comp on its own is not comparable to ->, good point. Once you add partial, I think a more direct comparison is possible. (let [& comp p partial ((& (p filter predicate) (p map function) (p remove other-predicate)) some-seq)) This is a lot closer to the new ->>. Anyw

Re: -> vs comp

Hmmm... good point about java interop. Didn't consider that. On Oct 17, 3:44 am, Timothy Pratley wrote: > On Oct 17, 1:22 pm, Sean Devlin wrote: > > > Given these reasons, I'd like to make a proposal. Contrib should be > > centered around closures, not ->. > > Hi Sean, > > -> seems to work nic

Re: -> vs comp

Hi. Am 17.10.2009 um 13:25 schrieb James Reeves: > Well, defining the "most important argument" can be tricky. However, > it would be nice if there were map and filter variants that could be > used with ->. There is also ->>. (->> some-seq (filter predicate) (map function) (remove othe

Re: -> vs comp

2009/10/17 James Reeves > > On Oct 17, 4:55 am, samppi wrote: > > Personally, I can go either way—I just kind of wish that there was a > > consistent practice for the placement of the most important argument, > > whether it's first or last, in both core and contrib. > > Well, defining the "most

Re: -> vs comp

On Oct 17, 4:55 am, samppi wrote: > Personally, I can go either way—I just kind of wish that there was a > consistent practice for the placement of the most important argument, > whether it's first or last, in both core and contrib. Well, defining the "most important argument" can be tricky. How

Re: -> vs comp

On Oct 17, 3:22 am, Sean Devlin wrote: > I have an idea in my head, and I can't quite put all the details > together.  The intent with of this posting is to start a healthy > debate of the merits of -> vs. comp.  I know people on this list will > think of something. I

Re: -> vs comp

On Oct 17, 1:22 pm, Sean Devlin wrote: > Given these reasons, I'd like to make a proposal. Contrib should be > centered around closures, not ->. Hi Sean, -> seems to work nicely for java interop in ways that comp does not. I think it has its place. (defn full-screen "Enables full-screen mo

Re: -> vs comp

On Fri, Oct 16, 2009 at 11:55 PM, samppi wrote: > Don't forget about the third piece of the puzzle, #() (and fn). > Whenever I need to create a function using ->, I just do #(-> % ...). > It's about as much typing as (comp ...). > > Personally, I can go either way—I just kind of wish that there w

Re: -> vs comp

ment of the most important argument, whether it's first or last, in both core and contrib. On Oct 16, 7:22 pm, Sean Devlin wrote: > I have an idea in my head, and I can't quite put all the details > together.  The intent with of this posting is to start a healthy > debate of the me

-> vs comp

I have an idea in my head, and I can't quite put all the details together. The intent with of this posting is to start a healthy debate of the merits of -> vs. comp. I know people on this list will think of something. After designing my own Clojure libraries for a while, I'

Re: -> vs. comp

      seq-utils/flatten > >                 ((fn [x] (interpose ", " x))) > >                 ((fn [x] (apply println x > > >     And I found the "->" notation marginally easier to interpret and > > understand. Apart from appearance, are there any ben

Re: -> vs. comp

uot;->" notation marginally easier to interpret and > understand. Apart from appearance, are there any benefits to using -> > instead of the comp function? I happily concede that there exist nicer > ways to achieve this goal, but the question I wanted to raise > concerned the bene

Re: -> vs. comp

((fn [x] (apply println x > >And I found the "->" notation marginally easier to interpret and > understand. Apart from appearance, are there any benefits to using -> > instead of the comp function? I happily concede that there exist nicer > ways to achieve this

Re: -> vs. comp

((fn [x] (apply println x > >And I found the "->" notation marginally easier to interpret and > understand. Apart from appearance, are there any benefits to using -> > instead of the comp function? I happily concede that there exist ni

-> vs. comp

ere exist nicer ways to achieve this goal, but the question I wanted to raise concerned the benefits of using -> vs comp or vice-versa. Kev Kev --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure"