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
