fluokitten does not have anything to do with haskell, or how haskell does those things. It is completely tailored to clojure. Regarding marsi0's task, now I see that, actually, foldmap is what should be used, and not fold. so, it's something like (foldmap dummy-nil-accumulating-fn nil side-effect-fn a b).
It does not create intermediate allocations. If you use neanderthal vectors/matrices for the data, even better! They support fluokitten, and keep everything primitive, so even objects are kept in check. I think that the best way is to try it in a simple project and see how it works. Maybe I am missing something, but it seems to me this is more or less what marsi0 is looking for. On Saturday, September 24, 2016 at 12:52:48 AM UTC+2, tbc++ wrote: > > How is this done, I searched the source, but there was so much indirection > I can't find it. I'm familiar with how Haskell does rfold vs lfold, but one > of those does create allocations, they may be in the form of closures, but > they are allocations none the less. So does fold use iterators or something? > > Timothy > > On Fri, Sep 23, 2016 at 4:23 PM, Dragan Djuric <drag...@gmail.com > <javascript:>> wrote: > >> fluokitten's fold is MUCH better than (map f a b) because it does NOT >> create intermediate collections. just use (fold f a b) and it would fold >> everything into one thing (in this case nil). If f is a function with side >> effects, it will invoke them. No intermediate collection is created AND the >> folding would be optimized per the type of a. >> >> On Friday, September 23, 2016 at 10:56:00 PM UTC+2, tbc++ wrote: >>> >>> How is fluokitten's fold any better than using seqs like (map f a b) >>> would? Both create intermediate collections. >>> >>> On Fri, Sep 23, 2016 at 11:40 AM, Dragan Djuric <drag...@gmail.com> >>> wrote: >>> >>>> If you do not insist on vanilla clojure, but can use a library, fold >>>> from fluokitten might enable you to do this. It is similar to reduce, but >>>> accepts multiple arguments. Give it a vararg folding function that prints >>>> what you need and ignores the first parameter, and you'd get what you >>>> asked >>>> for. >>>> >>>> >>>> On Friday, September 23, 2016 at 7:15:42 PM UTC+2, Mars0i wrote: >>>>> >>>>> On Friday, September 23, 2016 at 11:11:07 AM UTC-5, Alan Thompson >>>>> wrote: >>>>>> >>>>>> Huh. I was also unaware of the run! function. >>>>>> >>>>>> I suppose you could always write it like this: >>>>>> >>>>>> (def x (vec (range 3))) >>>>>> (def y (vec (reverse x))) >>>>>> >>>>>> (run! >>>>>> (fn [[x y]] (println x y)) >>>>>> >>>>>> (map vector x y)) >>>>>> >>>>>> >>>>>> > lein run >>>>>> 0 2 >>>>>> 1 1 >>>>>> 2 0 >>>>>> >>>>>> >>>>> Yes. But that's got the same problem. Doesn't matter with a toy >>>>> example, but the (map vector ...) could be undesirable with large >>>>> collections in performance-critical code. >>>>> >>>>> although the plain old for loop with dotimes looks simpler: >>>>>> >>>>>> (dotimes [i (count x) ] >>>>>> (println (x i) (y i))) >>>>>> >>>>>> >>>>>> maybe that is the best answer? It is hard to beat the flexibility of >>>>>> a a loop and an explicit index. >>>>>> >>>>> >>>>> I agree that this is clearer, but it kind of bothers me to index >>>>> through a vector sequentially in Clojure. We need indexing In Clojure >>>>> because sometimes you need to access a vector more arbitrarily. If >>>>> you're >>>>> just walking the vector in order, we have better methods--as long as we >>>>> don't want to walk multiple vectors in the same order for side effects. >>>>> >>>>> However, the real drawback of the dotimes method is that it's not >>>>> efficient for the general case; it could be slow on lists, lazy >>>>> sequences, >>>>> etc. (again, on non-toy examples). Many of the most convenient Clojure >>>>> functions return lazy sequences. Even the non-lazy sequences returned by >>>>> transducers aren't efficiently indexable, afaik. Of course you can >>>>> always >>>>> throw any sequence into 'vec' and get out a vector, but that's an >>>>> unnecessary transformation if you just want to iterate through the >>>>> sequences element by element. >>>>> >>>>> If I'm writing a function that will plot points or that will write >>>>> data to a file, it shouldn't be a requirement for the sake of efficiency >>>>> that the data come in the form of vectors. I should be able to pass in >>>>> the >>>>> data in whatever form is easiest. Right now, if I wanted efficiency for >>>>> walking through sequences in the same order, without creating unnecessary >>>>> data structures, I'd have to write the function using loop/recur. On the >>>>> other hand, if I wanted the cross product of the sequences, I'd use doseq >>>>> and be done a lot quicker with clearer code. >>>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "Clojure" group. >>>> To post to this group, send email to clo...@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+u...@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+u...@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 clo...@googlegroups.com >> <javascript:> >> Note that posts from new members are moderated - please be patient with >> your first post. >> To unsubscribe from this group, send email to >> clojure+u...@googlegroups.com <javascript:> >> 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+u...@googlegroups.com <javascript:>. >> 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.
