Although your original complaint was about clojure seqs being lazy. It should be noted that reducers are also lazy down to the point of a fold or reduce, so I'm not sure what you're really getting there. It wouldn't be hard at all to write map, filter, remove, etc. in terms of list operations. Perhaps that's what you're looking for? If I understand your original complaint, you want map, filter, etc, to be eager.
On the other hand, time spent learning how lazy seqs work, and the caveats involved will make it easier for you to understand the code produced by the rest of the community. So perhaps that's the better option. Timothy On Wed, Jun 4, 2014 at 11:20 AM, Gary Johnson <gwjoh...@uvm.edu> wrote: > Hey Lee, answers below. Also make sure to read my other post at 12:59pm > today regarding the behavior of vec vs. into for reducible collections. > > > On Wednesday, June 4, 2014 12:51:45 PM UTC-4, Lee wrote: >> >> Some quick notes and a question from my first look into this: >> >> - I watched a Rich Hickey reducers video, was riveted, and see that they >> are beautiful. I particularly appreciated his brief aside about how lazy >> seqs have independent utility. >> >> - In practice, for the little program I posted about previously, >> switching to reducers involved a couple of initially unexpected >> complications, some of now make sense to me but others of which don't >> fully: results of reducers sometimes have to be explicitly converted, e.g. >> with "into []"; r/map doesn't take multiple collections; I don't >> immediately see elegant reducer-based approaches to uses of "for" or >> "repeat", etc. >> >> > It's true that the library does have these limitations. You could, of > course, just implement a for-like macro that uses the reducing operations > under the hood. Easier (but less readable) is to just convert your for into > the equivalent r/map and r/filter operations. When using repeat, make sure > the result sequence will be finite and call vec on it directly. Then you > can apply the reducing functions to it and still have a foldable collection. > > >> - My initial swapping of clojure.core.reducers functions for lazy seq >> (and agent-based parallel computing) functions seems to make my performance >> worse rather than better. I realize that there are several possible >> explanations for this and I have to look at my usage more carefully. It's >> definitely possible that I'm doing more than one thing wrong, but one >> question that this leads to is: >> >> > Hard to say why this would be without seeing your code, but the first > thing that comes to mind is that if you aren't calling fold or foldcat > anywhere, then you won't be getting any parallelization from using > reducers. So maybe your performance decrease is because you're now running > single-threaded. > > >> - If I operate on a vector with a sequence of r/map and r/filter >> operations and finally with "into []" to get back a vector, then I think >> that fold will be called within the call to into, and that parallelism >> should happen there... right? But if that's right, how do I control the >> group size that the call to fold uses in this case? I see how to specify >> the group size for a direct call to fold, but not for other function in the >> library. >> >> > No, fold will not be called in into. The definition of into uses reduce, > which is single-threaded. What you want is one of the following two > formulations: > > (fold group-size cat append! foldable-collection) ;; if you want to > specify the group size > > (foldcat foldable-collection) ;; if you are happy with the default 512 > group size > > In both cases, the foldable-collection is just one of your (r/map f > (r/filter p? initial-collection)) forms. For it to be foldable though, > initial-collection needs to be a vector, map, or set (i.e., a tree-like > collection). > > I hope that helps. > > ~Gary > >> Thanks, >> >> -Lee > > -- > 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 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.
