+1 consistency, whether it throws an exception or not, removes complexity from the language. (because the programmer don't have to know the complex rules which literal notation behaves which way
On Tue, Sep 4, 2012 at 10:02 PM, Andy Fingerhut <andy.finger...@gmail.com>wrote: > 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 > -- 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
