The first thing I can think of is that filter is lazy. You side effects won't occur when you think they will. Generally if you're dealing with side-effects over a sequence, it's time to think about using a macro, such as doseq.
In your specific case, I'd recommend using a custom form of reduce, something that returned [your-filtered-seq last-element] HTH, Sean On Feb 18, 9:04 am, Rowdy Rednose <rowdy.redn...@gmx.net> wrote: > The filter documentation reads: > > "Returns a lazy sequence of the items in coll for which (pred item) > returns true. pred must be free of side-effects." > > So that means I should not write a function like this: > > (defn unique [sc] > "Returns a lazy sequence with all consecutive duplicates removed" > (let [last (atom (Object.))] > (filter #(let [ok (not= @last %)] (reset! last %) ok) sc))) > > user=> (unique [1 2 3 3 4 5 5 6]) > (1 2 3 4 5 6) > > But in contrast to functions that can be retried (compare-and-swap > etc.), I don't immediately see why having side effects in filter would > be bad. Can anybody enlighten me? And how should I do this instead? > > Thanks -- 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
