2009/4/23 Christophe Grand <christo...@cgrand.net>: > > Laurent PETIT a écrit : >> 2009/4/23 Christophe Grand <christo...@cgrand.net>: >> >>> *Warning this message contains mutable state and may hurt functional >>> sensibilities.* >>> >>> Ugly hack: >>> >>> (defn my-split-with [pred coll] >>> (let [s (atom coll) >>> p #(when-let [r (pred %)] (swap! s rest) r)] >>> [(take-while p coll) (drop-while pred (lazy-seq @s))])) >>> >> >> Cheater ! ;-) >> >> But there's still the problem of having the user being able to check >> the second argument before having exhausted (if possible) the first... >> and then having an infinite loop: e.g. (first (second (my-split-with >> true? (repeat true))). >> > > I don't see the problem, it's like (dropwhile true? (repeat true)) you > can't protect the user from himself.
I guess you're right. But a little warning in the javadoc could help newcomers not shoot themselves in the foot. And the problem is, calling directly (second) without calling (first) would work most of the time. I wanted to make it fail every time => same behaviour whatever the input data are. And it could also be counterintuitive : a user could think that if he knows the predicate will always return true, maybe the second seq will be nil, since it is the mathematically expected result :-) With dropwhile there's no option for the user. > > >> And maybe calling swap! for each matched elem may be expensive ? >> (That's a real question, I don't have any real idea, just a guess ...) >> > > Neither do I. Updates to the atom are serialized by the lazy-seq > realization, so we don't even need an atom: a simple volatile field > should do the trick. No? Yes, what would be the prettier way to do this ? I could think of some hackish but working array of one element :-) ? I don't think (with-local-vars will work, since the produced seqs could not be transported among threads anymore). > > >> But wait ... the more I think about it, the more it appears to me >> (though I can not prove it formally) that the problem requires >> side-effect to be solved, either via the use of mutation, either via >> the use of multiple threads for coordinating the feeding of 2 separate >> sequences ? >> > > I share your intuition on this. --~--~---------~--~----~------------~-------~--~----~ 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 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 -~----------~----~----~----~------~----~------~--~---
