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

Reply via email to