I think there are two important considerations in favor of how it works now:
(1) The "common case" presumptions (which admittedly may need to be learned). (2) The need for both flavors. If there wasn't a flavor that rejected duplicate keys, somebody would surely ask for it. Add to these considerations the names of the functions already in play, and you get the implementation you see. > On Fri, 25 Jun 2010 10:31:57 -0400 > Stuart Halloway <stuart.hallo...@gmail.com> wrote: > >> Duplicate keys in maps/sets are disallowed in literals and factory >> functions, where data is generally literal & inline and therefore likely >> represents coder error: >> >> ; all disallowed >> #{:a :a} >> {:a 1 :a 2} >> (hash-map :a 1 :a 2) >> (hash-set :a :a) > > Maps I can see being an error - you lose data in the process. > > However, since you can plug variables of unknown provenance into > either the constructor or the literal, that's liable to create a nasty > surprise for someone at some point. > > user=> (def a :a) > #'user/b > user=> (def b :a) > #'user/b > user=> (hash-set a b) > java.lang.IllegalArgumentException: Duplicate key: :a (NO_SOURCE_FILE:6) > user=> #{a b} > java.lang.IllegalArgumentException: Duplicate key: :a (NO_SOURCE_FILE:0) > user=> > > >> They are allowed in other contexts, where the data could come from anywhere: > > It could come from anywhere in the two "forbidden" contexts as well. > >> ; dumb, but these forms not generally called with a literal >> (set [:a :a]) >> (into #{} [:a :a]) >> >> I find this behavior consistent and easy to explain, but I was involved in >> the design conversation so maybe I have participant blindness. :-) > > My initial reaction was "that's a bit odd, but probably a good idea." > However, given that I can use variables inside the literal and > constructor, I'm leaning the other way. > > Or is (set [a b c]) idiomatic usage in this case, and (hash-set a b c) > or #{a b c} to be avoided? > > <mike > -- > Mike Meyer <m...@mired.org> http://www.mired.org/consulting.html > Independent Network/Unix/Perforce consultant, email for more information. > > O< ascii ribbon campaign - stop html mail - www.asciiribbon.org -- 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