Hi Stuart, I agree that the main problem here should be solved at the merge(-with) level. A couple of thoughts on this issue:
On 8 July 2010 21:16, Stuart Halloway <stuart.hallo...@gmail.com> wrote: > Useful? Am I crazy? (Not mutually exclusive.) I'm inclined to think both. :-) I think that a "merge-reduce" function would be very useful indeed (I for one would definitely have more use for it than for the current merge-with), though ultimately I'd see it working along the lines of (defn merge-reduce ([maps] (merge (fn [_ x] x) maps)) ([f maps] (merge f nil maps)) ([f seed maps] ...)) This gives rise to at least two crazy possibilities: 1) call the above "merge" and allow it to supersede the current merge and merge-with; 2) just add it on top of the above two. 1) means breaking old code, which doesn't seem appealing at all, while 2) introduces a third core function which has the functionality of two other core functions built-in and follows a different calling convention while having a very similar name... Oh, the confusion. If the current signature with the "maps" argument being unrolled is preferred, than I wonder if we could simply have a third variant taking [f seed & maps]. Seems slightly wasteful, but then again, it's no big deal and keeps things consistent. Sincerely, Michał -- 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