But what if they all consistently throw exceptions when encountering duplicates, including (set [5 5])? That doesn't sound like what you want.
Also, it seems from this discussion that at least some people like the error-catching aspects of the current behavior. Stuart Halloway mentioned the idea of having two kinds of set/map constructor functions, one kind which quietly eliminates duplicates, another which throws an exception on duplicates. That still leaves open the question of what the set and map literals should do with duplicates. What if the default behavior for set & map literals were to quietly allow duplicates, with a new compiler option like the following that would give the error, for those that like it? (set! *error-on-duplicates* true) Perhaps it is starting to look like feature creep, but I thought I'd throw out the idea to see what happens. Andy On Sep 4, 2012, at 10:08 AM, Jim - FooBar(); wrote: > the issue here is that behaviour should be *consistent* across all forms of > ctor functions, so programmers don't have to remember which one allows what > or don't thus limiting code breaks...the literal syntax is just too elegant > to give up! I don't think anyone is against consistency... > > Jim > > ps: IMO sets should always remove duplicates quietly...that is the whole > point of using them programmatically! > > > On 04/09/12 17:30, Andy Fingerhut wrote: >> I have created a dev page for this issue. It isn't a JIRA ticket because it >> isn't clear to me yet exactly what the changes should be. >> >> http://dev.clojure.org/display/design/Allow+duplicate+map+keys+and+set+elements >> >> A couple of questions there for people that dislike the current behavior. >> >> You can always construct sets that quietly allow duplicates as follows. Is >> that good enough? Or perhaps the issue is that you prefer to use #{} >> notation for constructing sets, and do not want to have to use a different >> method if you want the silent-duplicate-elimination behavior? If so, I can >> understand that. I'm just trying to get the argument for change as clearly >> as possible. >> (set [a b]) >> >> The story for creating maps that quietly use the later duplicate keys in >> preference to the earlier ones isn't as clean: both hash-map and array-map >> throw an exception on duplicate keys, although sorted-map does not for some >> reason (probably an oversight when the duplicate key checks were added?). >> The following works, but is a bit clunky: >> >> (assoc {} a 5 b 7) >> >> Thanks, >> Andy >> >> >> On Sep 3, 2012, at 7:49 PM, Sean Corfield wrote: >> >>> On Mon, Sep 3, 2012 at 6:06 PM, Mark Engelberg <mark.engelb...@gmail.com> >>> wrote: >>>> I don't know what the path is now. I feel that in the past year, there >>>> have >>>> been several times where people have raised meaningful issues about Clojure >>>> and received no official response. It's hard to know whether this is an >>>> intentional "rejection through ignoring", or whether it's just that those >>>> messages happened to slip beneath the radar. Maybe Rich didn't see them, >>>> and without his go-ahead, no one moved forward with them. >>> My understanding is the sort of discussion you are referring to has >>> moved to clojure-dev by necessity because of the volume of posts on >>> this list. http://clojure.org/contributing hints as much. >>> >>> My understanding is also that anyone can open an issue in JIRA for >>> something they believe is a bug. >>> >>>> In any case, there was a great deal of useful discussion about the set >>>> issue, and then... silence. >>> Open an issue in JIRA. Ask the folks here who agreed with your point >>> of view to "vote" on the issue. All issues get raised on clojure-dev >>> one way or another (esp. if they have a patch attached). >>> >>>> example, on whitehouse.gov, you can start a petition and if enough people >>>> sign the petition within a given length of time, the president's office >>>> will >>>> issue an official statement about it. That's the kind of thing I'm >>>> thinking >>> That would seem to match the "voting on JIRA issues" point above. >>> >>>> 2. There was significant support for my suggestion to revert set behavior >>>> back to 1.2 and solve the problem which motivated the change by bringing >>>> array-maps into accord with the behavior of the other maps and sets. This >>>> email is also my way of bumping the thread and bringing it again to >>>> everyone's attention. This is something I'd very much like to see >>>> resolved. >>> Again, open an issue in JIRA with a patch (you have a signed CA on >>> file so there's no obstacle). That will guarantee the issue gets >>> reviewed. -- 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
