Throwing a runtime error for duplicates in set literals is, to me,
shockingly counterintuitive, regardless of whether constants or
non-constants are in the literal. Mathematical set notation has a long
history of admitting duplicates, for clarity in exposition, which are
understood to collapse to single values. Perhaps the most common usage of
sets in a programming language is reducing duplicates, so not allowing such
duplicates is just weird to me.
One might argue that such an error should be raised only when the
duplicates are constants, but that sort of special-casing of behavior would
likely lead to irritating ambiguities. For example, should (read-string
"#{1 1}") throw an error? What if the string being read were constructed by
some other function? What about a macro that expands into #{1 1}, but
doesn't actually have that literal in its definition? Should that be an
error or not? If not, how would the compiler know not to throw an error?
The case for throwing an error on duplicate keys in literal maps (other
than sets) is a slightly stronger, but strikes me as a bit nanny-state-ish,
protecting ourselves from ourselves, while removing a potentially useful
capability. Allowing the last duplicate key to override strikes me as often
quite useful, especially when the keys and values are non-constants.
...oh, and regarding the people who argue we should not use literal syntax
with non-constants, I can only shake my head in wonder. Why on Earth would
anyone seriously propose not using this elegant, concise syntax?
--
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
