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 can’t
condone. ;)
Let me offer an explanation as to why I
Correction after actually trying it out:
In this case you might prefer to write something like (transduce xform
(comp group-by-xf +) ...) instead
of (transduce (comp xform group-by-xf) + ...) . [...]
The first variant must use a valid rf, and needs to be written
as (transduce xform
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
Am Freitag, 17. Oktober 2014 15:01:51 UTC+2 schrieb Daniel James:
[...]
Your function is good for use with `reduce`, but only that. I hope I’ve
helped build an intuition for why it’s actually impossible to implement
‘group by’ as a transducer.
This is correct. Unlike you, I am
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
Am Freitag, 17. Oktober 2014 15:52:49 UTC+2 schrieb Daniel James:
[...]
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 ...)
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:
;;
Am Mittwoch, 15. Oktober 2014 18:34:39 UTC+2 schrieb Daniel James:
[...]
In my proposal above, nothing is changing about the fact that transducers
transform reducing functions to new reducing functions. The simple change
is to use the reducing function that is produced by a transformation
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
Dan, I haven't read yours or Christophe Grand's articles thoroughly enough
even to know whether your ideas are similar, but you may be interested to
read this thread, and the blog posts written by Christophe, linked from his
first message in this discussion thread:
Hi Andy,
Thanks for the reference. I had already read Christophe’s blog posts, and
had seen some of the the discussion around them. I can attempt to offer a
comparison of what is being proposed.
Christophe is proposing changing the types. To illustrate this, in his
formulation, the identity
13 matches
Mail list logo
