On Oct 17, 2014 9:21 AM, "Michael van Acken" <michael.van.ac...@gmail.com> wrote: > > This is correct. Unlike you, I am exclusively talking about the reduce case: transformations on reducing > functions, and the general init-reduce-complete cycle represented by the 0/2/1-arities of the reducing > functions. My use case is a reduce using the reducing function (xform f), but by default transduce > does not pick this reducing function's 0-arity for its init value, but rather uses (f) instead.
Great, Michael, I think we're both on the same page. After all that, I was ultimately arguing that it is technically incorrect to say: “… trying to splice a group-by-style *transducer* into an existing (comp ...) chain.” (emphasis mine) As you can tell, I come to transducers with type-theory in mind, but I'm actually equally interested in the the algebraic properties of transducers, if not more so. Why? Because these can be formulated as property-based tests (using test check, for example) and then used to search for counter examples against functions that claim to be transducers. I also feel that these, along with types, would be helpful in characterizing the boundaries of what can and can't be expressed as a transducer. Dan -- 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.
