On Jun 15, 11:51 am, Mark Engelberg <mark.engelb...@gmail.com> wrote: > On Tue, Jun 14, 2011 at 7:41 PM, Matthew Phillips <mattp...@gmail.com> wrote: > > Yes. I agree that can work, and that's what I've done in some other > > situations, but it has the downside of lots of "recur" points > > sprinkled around the loop body, which I think makes it almost as hard > > to reason about as having lots of "return" statements in a Java > > method. For small problems like this it's just as good/bad as my > > solution, but what I'm really looking for is a good general idiom to > > use whenever this sort of thing comes up. > > To summarize what others have already pointed out, the main problem > with your approach is that you're trying to do to much in the loop. > It's convertible to Clojure, but clunky to read. The key to making > this readable is to focus on writing a separate function of the form: > > processOp: items op -> items > > If you have such a function, the loop is trivial (or use reduce as in > your original post).
Wouldn't such a processOp be the same as the anonymous fn in my reduce- based example? I'm really asking how to write that fn better or, more generally, what is a good idiom for threading conditional transformations. I think I'll pursue the -> (or ->>) based approach and see where it leads, because it seems to fit best with my mental model of pipelining data transforms. And it's entirely possible that I'm over-thinking this, but I treat it as part of learning how to use this tool in its most effective way, rather than just mentally translating Java into Clojure ;) -- 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
