OK, so would you say it's *not* good practice to do: (r/reducer [1 2 3] (map f))
instead of (r/map f [1 2 3]) because the former doesn't create a reducer that handles kv-reduction? If so, it seems that `folder`/`reducer` are not fns intended for public consumption, since `rfn` is private and there's no easy way to create reducing function transformers that work with `folder`/`reducer`. Is this the case? Creating a reducer from a transducer may not be very useful, given that `reduce`/`transduce` can be used to get *sequential* reduction either way. Creating a *folder* from a transducer, however, seems like it'd be useful--the transducer captures the *what*, while the folder captures the *how* (parallel via fork/join). So it'd be nice if (r/folder [1 2 3] xf) was the way to do it. On Friday, May 19, 2017 at 8:11:47 AM UTC-7, Alex Miller wrote: > > This is a place where reducers and transducers diverge. Transducers don't > have support for automatic kv reducing (there are some tricky details as to > why this was possible in reducers but not as easy in transducers, which I > mostly don't remember at this point). That is an area of possible future > extension. > > > > On Friday, May 19, 2017 at 12:49:09 AM UTC-5, Tianxiang Xiong wrote: >> >> I think this is one of those cases where I need to see an example to >> understand. >> >> From what I can tell, the `(fn [f1] (rfn ...))` argument to `folder` is a >> reducing-function-transformer--i.e. transducer, except there are some >> differences in things like order of application in composition. I *don't* >> see >> this 3-arity case for the transducer version of `clojure.core/map`. >> >> In my mind, the following are equivalent >> >> (r/reducer [1 2 3] (map f)) >> >> (r/map f [1 2 3]) >> >> So the following should be equivalent: >> >> ;; Reducer >> (fn [f1] >> (rfn [f1 k] >> ([ret k v] >> (f1 ret (f k v))))) >> >> ;; macroexpands to >> (fn [f1] >> (fn >> ([] (f1)) >> ([ret v] (f1 ret (f v))) >> ([ret k v] (f1 ret (f k v))))) >> >> ;; and should be equivalent to the transducer (map f): >> (fn [rf] >> (fn >> ([] (rf)) >> ([result] (rf result)) >> ([result input] >> (rf result (f input))) >> ([result input & inputs] >> (rf result (apply f input inputs))))) >> >> >> Yet they are clearly *not* the same: there is nothing in the transducer >> about `[ret k v]`. So I must be missing something fundamental about the >> relationship between reducers and transducers. >> >> >> On Thursday, May 18, 2017 at 9:34:54 PM UTC-7, Alex Miller wrote: >>> >>> Reducers combine functionally, so they all have to support it to create >>> any composite reducer that contains map. >>> >>> On Thursday, May 18, 2017 at 10:11:23 PM UTC-5, Tianxiang Xiong wrote: >>>> >>>> Would that ever be the case for `r/map`? Or does it only apply to >>>> certain other reducers? >>>> >>>> On Thursday, May 18, 2017 at 4:11:39 PM UTC-7, Alex Miller wrote: >>>>> >>>>> The 3 arity is used when reducing over a map, like reduce-kv. Reducers >>>>> do this automatically which varies from the core reduce. >>>> >>>> -- 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/d/optout.
