Hi Mark,
Thanks for extracting a summary of the conversation so far, and +1 for making
sure this is on the wiki.
Stu
> On Tue, Sep 4, 2012 at 9:30 AM, Andy Fingerhut <andy.finger...@gmail.com>
> wrote:
> I'm just trying to get the argument for change as clearly as possible.
>
> The major bullet points:
> 1. "It's a bug that should be fixed." The change to throw-on-duplicate
> behavior for sets in 1.3 was a breaking change that causes a runtime error in
> previously working, legitimate code.
>
> Looking through the history of the issue, one can see that no one was
> directly asking for throw-on-duplicate behavior. The underlying problem was
> that array-maps with duplicate keys returned nonsensical objects; surely it
> would be more user-friendly to just block people from creating such nonsense
> by throwing an error. This logic was extended to other types of maps and
> sets.
>
> It's not entirely clear the degree to which the consequences of these changes
> were considered, but it seems likely that there was an implicit assumption
> that throw-on-duplicate behavior would only come into play in programs with
> some sort of syntactic error, when in fact it has semantic implications for
> working programs. When a new "feature" causes unintentional breakage in
> working code, this is arguably a bug and needs to be reconsidered.
>
> 2. "The current way of doing things is internally inconsistent and therefore
> complex."
> (def a 1)
> (def b 1)
> (set [a b]) -> good
> (hash-set a b) -> error
> #{a b} -> error
> (sorted-set a b) -> good
> (into #{} a b) -> good
>
> The cognitive load from having to remember which constructors do what is a
> bad thing.
>
> 3. "Current behavior conflicts with the mathematical and intuitive notion of
> a set."
> In math, {1, 1} = {1}. In programming, sets are used as a means to eliminate
> duplicates.
>
>
> Many people have +1'd and reiterated variations of the above arguments. Now
> let's summarize the arguments that have been raised here in support of the
> status quo.
>
> 1. "Changing everything to throw-on-duplicate would be just as logically
> consistent as changing everything to use-last-in."
>
> True, but that doesn't mean that both approaches would be equally useful.
> It's readily apparent that an essential idea of sets is that they need to be
> able to gracefully absorb duplicates, so at least one such method of doing
> that is essential. On the other hand, we can get along just fine without
> sets throwing errors in the event of a duplicate value. So if you're looking
> for consistency, there's really only one practical option.
>
> 2. "I like the idea that Clojure will protect me from accidentally from this
> kind of syntax error."
>
> Clojure, as a dynamically typed language, is unable to protect you from the
> vast majority of data-entry syntax errors you're likely to make.
>
> Let's say you want to type in {:apple 1, :banana 2}. Even if Clojure can
> catch your mistake if you type {:apple 1, :apple 2}, there's no way it's ever
> going to catch you if you type {:apple 1, :banano 2}, and frankly, the latter
> error is one you're far more likely to make.
>
> This is precisely why there's little evidence that anyone was asking for this
> kind of syntax error protection, and little evidence that anyone has
> benefited significantly from its addition -- its real-world utility is fairly
> minimal and dwarfed by the other kinds of errors one is likely to make.
>
> 3. "Maybe we can do it both ways."
>
> It's laudable to want to make everyone happy. The danger, of course, is that
> such sentiment paints a picture that it would be a massive amount of work to
> please everyone, and therefore, we should do nothing. Let's be practical
> about what is easily doable here with the greatest net benefit. The current
> system has awkward and inconsistent semantics with little benefit. Let's
> focus on fixing it. The easiest patch -- revert to 1.2 behavior, but bring
> array-map's semantics into alignment with the other associative collections.
>
--
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
