Great to see that it's on the cards. Really looking forward to be able to
use this when stable. Also, wouldn't transducers also open up the way to
define the chunking size of transduced lazy operations ? Something like
(with-chunk-size 1 (xform data)) ? Or would this make chunking a non-issue
a
This is not safe usage, as you are not calling the 'flushing' method
or handle reduced objects. Correct use would be
(def xform (comp (filter odd?) (map #(* % %
(def strip-reduced [x] (if (reduced? x) @x x))
(let [r (xform conj)] (strip-reduced (r (strip-reduced (r #{1 2 3}
7) ;=> #{1 3 2
Some alternate transducers usage:
(def xform (comp (filter odd?) (map #(* % %
((xform conj) #{1 2 3} 7) ;=> #{1 3 2 49}
((xform conj) [1 2 3] 6) ;=> [1 2 3]
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo
I doubt I can answer this as clearly as Rich or others but...
I think the answer to this lies in the fact that composing transducers is
composing reducer-transformers not reducer functions themselves.
When composing reducer-transformers, the result is another transformer.
When this new transfo
I'm also curious to understand how the underlying implementation of
transducers leads function composition to behave in the reverse order of
ordinary function composition.
On Thu, Aug 7, 2014 at 8:07 AM, wrote:
> Hello, what is the reason for comp to produce two different orderings
> depending
Just wanted to add that all of the current transducers work in Clojure
is now available in ClojureScript master.
David
On Wed, Aug 6, 2014 at 2:01 PM, Rich Hickey wrote:
> I pushed today the initial work on transducers. I describe transducers
> briefly in this blog post:
>
> http://blog.cognite
Hello, what is the reason for comp to produce two different orderings
depending on whether it composes partials or transducers?
(comp (partial filter even?) (partial map (partial + 1)))
(comp (filter even?) (map (partial + 1)))
Wouldn't it be more intuitive for upcoming clojurians to have both
Oh dear, I still haven't understood the blogpost on reducers yet, and
now there is this one as well.
Phil
Rich Hickey writes:
> I pushed today the initial work on transducers. I describe transducers briefly
> in this blog post:
>
> http://blog.cognitect.com/blog/2014/8/6/transducers-are-comin
The integration with reducers is still todo.
On Aug 7, 2014, at 7:03 AM, Niels van Klaveren
wrote:
> Will the new transducer abstraction also (partly) replace / incorporate the
> reducer library ?
> So we could do something like (def xform (comp (fold +) (map inc) (filter
> even?))) to lever
Will the new transducer abstraction also (partly) replace / incorporate the
reducer library ?
So we could do something like (def xform (comp (fold +) (map inc) (filter
even?))) to leverage parallelism ?
On Wednesday, August 6, 2014 8:01:24 PM UTC+2, Rich Hickey wrote:
>
> I pushed today the ini
Thanks Rich!
Transducers, like all of your releases, are an eye opener.
I've always felt slightly hesitant to use core.async's version of sequence
functions, because of the overhead of intermediate channels. Then there was
the strictness tradeoff with reducers. All of that complexity, gone from m
Looks nice, although I still need to wrap my head arround it.
I don't believe in micro-benchmarks but I did one anyways cause I was
curious how transduce would stack up against reduce (not reducers).
https://github.com/thheller/transduce-bench
transduce
Evaluation count : 2220 in 60 samples of
Thank you for another great technique and concept!.
I've been using reducers a lot lately and I've found that it is in some
cases better (performance, fold support) to wrap local state in the
intermediate result, rather than to keep it in an atom. See this *very*
simplified example for
compari
if I'm reading the source correctly, ((partial map f) something) and ((map
f) something) are completely different, yes?
On Wed, Aug 6, 2014 at 1:13 PM, Alex Miller wrote:
>
>
> On Wednesday, August 6, 2014 2:20:38 PM UTC-5, Robin Heggelund Hansen
> wrote:
>>
>> I just want to check that I under
On Wednesday, August 6, 2014 2:20:38 PM UTC-5, Robin Heggelund Hansen wrote:
>
> I just want to check that I understand this. Instead of returning and
> manipulating lazy-seqs, you compose functions
>
yes
> (sort of like they way you would in Haskell?)
>
> which return reqular seqs (non-
I just want to check that I understand this. Instead of returning and
manipulating lazy-seqs, you compose functions (sort of like they way you
would in Haskell?) which return reqular seqs (non-lazy).
So I guess the upside is more flexibility, but you get eager-evaluation. Or
am I misunderstandi
16 matches
Mail list logo
