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). It's hard to know the cleanest way to write such a function without knowing the details of your problem, but that's really the key. -- 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
