Hi, 2009/6/14 CuppoJava <patrickli_2...@hotmail.com>: > > I actually really do like the reduce with early exit abstraction. > Because ultimately, that's what the question is. It's a reduce with > optimization. > > However, I feel that Laurence's reduce is a little too specific. The > early exit condition is very likely to *not* depend on the reduce > accumulator, but rather on some intermediate calculation in the reduce > function. > > It is possible to write something like this. But some people might be > concerned with how idiomatic this is. > > (my_reduce (fn [a b c] (if bla-bla (break))) initial_value collection)
Yes, I suggested a similar alternative in my email also: "Another way to implement the new version of reduce would be by having the 4th parameter be an explicit "early-return value", and let the "do we return early ?" test be part of the reduction function ?" which is similar to what you say, while maybe a little bit more general (in the sense it does not introduce a symbol), and also maybe a little bit easier for implementing my_reduce : (my_reduce (fn [a b c] (if bla-bla :early-break)) initial_value collection :early-break) > > where (break) exits the immediate surrounding reduce. > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
