These functions (as-transducer, transducing) are still completely agnostic about the type of the accumulator and result as long as the function you give them only touches result in the following ways:
1. Return result unchanged 2. Return (xf (xf result X) Y), I.e. Whatever you get from applying xf to result with a value to add, one or many times. (In case result is mutable, eg a channel, or the transformation is stateful, never call xf unless you plan to use the return value.) 3. (reduced result) 4. Both 3 and 4 The advantage of writing a full transducer (or as-transducer/transducing) is that the step arity is truly a reduction-step function and so can efficiently not change the result, add multiple items, or short-circuit reduction (or even a different thing each time). Normally data transformations don't do more than one of these at a time, so map or mapcat or filter is fine. But when the transduction is modeling a process (I.e read input, possibly keeping old state, and unpredictably emit 0, 1, many results based on the input) it is handy to be able to do exactly what you mean instead of using mapcat/map/filter/keep etc with intermediate collection or sentinel value contortions. It's also nice not to have an intermediate collection (mapcat) if you need to reduce object allocations. Sent from my iPhone > On Jun 11, 2016, at 1:20 AM, Timothy Baldridge <tbaldri...@gmail.com> wrote: > > Touching the accumulator (the result in your case) from within a transducing > function is a bit of an anti-pattern. The whole point of transducers is that > you can swap out the accumulator: > > (transduce (map inc) conj [] (range 10)) > (transduce (map inc) async/>! some-channel (range 10)) > (transduce (map inc) + 0 (range 10)) > > In this example, we loose that ability to swap out the result type if `(map > inc)` assumes that the accumulator will always be a vector, or a integer. > This is why I said map/filter/keep should handle most of your cases. > > If the function you are writing doesn't require the accumulator to function > properly, then there is no reason why `(map my-fn)` won't work. > >> On Sat, Jun 11, 2016 at 12:13 AM, Travis Daudelin >> <travis.daude...@gmail.com> wrote: >>> On Friday, June 10, 2016 at 3:03:38 PM UTC-7, Francis Avila wrote: >>> A higher-order function can do what this macro does: >>> https://gist.github.com/favila/ecdd031e22426b93a78f >> >> Oh nice! It looks like I came up with an almost identical solution: >> (defn transducing >> [f] >> (fn [reducing-fn] >> (fn >> ([] (reducing-fn)) >> ([result] (reducing-fn result)) >> ([result input] (f result input reducing-fn))))) >> >> It feels like "writing a custom transducer" should be a common use case, is >> there anything like these functions we've written that exists in the core >> library? I didn't see anything like them there or in the reducers library >> when I first started on my project. >> -- >> 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. > > > > -- > “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 a topic in the Google > Groups "Clojure" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/clojure/-XIekEB6zu0/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- 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.
