> I'm all for optimizing for size here, however, the fact that these
> functions happen to work when the second argument is not a set is an
> implementation artifact and not a promise of the interface, so I'm not
> in favor of the set? testing or any other accommodation of that.
OK, from that I take it the Clojure way is to not call "set" on the
arguments either, and let whatever happens happen if you pass the
functions non-sets? Note that here this has the potential to be
especially confusing since, e.g., (union #{1 2 3} [4 5]) might succeed
while (union #{1 2} [3 4 5]) would error.
Second, should this be combined with this issue to make efficient
versions that take any number of arguments?
http://code.google.com/p/clojure/issues/detail?id=52&colspec=ID%20Type%20Status%20Priority%20Reporter%20Owner%20Summary
> An issue w/patch for this would be welcome.
Finally, I don't know how to make a patch, and found nothing in a
quick search of the wiki/newsgroup/website. I heard "Git" floating
around somewhere earlier; am I to check out the SVN with git-svn and
make a patch that way?
-Jason
--~--~---------~--~----~------------~-------~--~----~
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
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
-~----------~----~----~----~------~----~------~--~---
