On Friday, October 17, 2014 2:58:20 AM UTC-4, Michael van Acken wrote:
Am Freitag, 17. Oktober 2014 04:02:52 UTC+2 schrieb Daniel James:
Hi Michael,
I’m glad you are in favor of this change; however, and with tongue firmly
in cheek, you’ve taken a beautiful thing and corrupted it, which I
Just a quick follow up to add some clarifications…
On Friday, October 17, 2014 7:11:12 AM UTC-4, Daniel James wrote:
Hi Michael,
As I said above, while this is certainly a function that transforms one
reducing function into another, you should not call this a transducer. It
is something
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
On Friday, October 17, 2014 10:24:32 AM UTC-4, Michael van Acken wrote:
Ah, understood. I am using the term as in http://clojure.org/transducers,
where it is defined as
A *transducer* (sometimes referred to as xform or xf) is a transformation
from one reducing function to another:
;;
On Thursday, October 16, 2014 1:54:03 AM UTC-4, Michael van Acken wrote:
This is a change I am interested in as well. Just yesterday I was bitten
by the fact that in
the 3-arity case the init value of transduce defaults to (f) instead of
((xform
f)):
While experimenting I was trying
Hi All,
I’d like to offer an alternative implementation of clojure.core/transduce.
(I’ve done some searching, and I didn’t find any evidence that this has
been raised before, but my apologies if I missed anything.)
This alternative is best motivated by example. Consider the following
be interested to
read this thread, and the blog posts written by Christophe, linked from his
first message in this discussion thread:
https://groups.google.com/forum/#!topic/clojure-dev/cWzMS_qqgcM
On Wed, Oct 15, 2014 at 6:22 AM, Daniel James dwhj...@gmail.com
javascript: wrote:
Hi All,
I’d
