Rich: I'm not sure what you mean by the not-fastest-path possible that exists in today's Clojure code, so if you get a chance, see if the below is what you mean.
As far as I can tell (i.e. putting debug println's in the Java code of RT.map), when someone enters a map literal in, say, a function definition, and all keys *and* values are compile time constants, it calls RT.map() while the function is being compiled, but never again when the function is called. If I make a similar function with run-time variable keys or values, RT.map() is called every time the function is invoked. Each of these calls repeats the check that the keys are unique. Do you mean that you want a new code path where if the keys are compile time constants, but the values are variables at compile-time, then at run time this map should be created with a method that avoids the unnecessary check for unique keys? And by the word "restore" do you mean to imply that it was this way at one time before? Thanks, Andy On Sep 8, 2012, at 5:29 AM, Rich Hickey wrote: > Thanks! > > I'm still interested in patch for recommendation #3: > > Restore the fastest path possible for those cases where the keys are > compile-time detectable unique constants > > I'd like to see all three recommendations go into a release as a set. > > > On Sep 8, 2012, at 2:22 AM, Andy Fingerhut wrote: > >> The new ticket CLJ-1065 has a patch that I think implements the desired >> behavior on the dev wiki page. >> >> i.e. set/map literals with duplicates are invalid (status quo) >> >> All constructor functions for sets and maps allow duplicates, and for maps, >> always take the value associated with the last occurrence of the same key. >> All constructor functions explicitly say this in their doc strings. >> >> Andy >> >> On Sep 7, 2012, at 2:06 PM, Rich Hickey wrote: >> >>> >>> On Sep 7, 2012, at 3:35 PM, Sean Corfield wrote: >>> >>>> On Fri, Sep 7, 2012 at 10:49 AM, Rich Hickey <richhic...@gmail.com> wrote: >>>>> I've added my feedback there >>>>> (http://dev.clojure.org/display/design/Allow+duplicate+map+keys+and+set+elements) >>>> >>>> Thanx Rich! So the recommendation is: >>>> >>>> * set/map literals with duplicates are invalid (status quo) >>>> >>>> * hash-set/hash-map should change (to last key wins, as if conj'd/assoc'd) >>>> >>>> * sorted-set/sorted-map should not change (last key wins, as if >>>> conj'd/assoc'd) >>>> >>>> * array-map should not change (throws on dupes)? >>>> >>>> Highlighting that last one since it's not mentioned on the wiki and >>>> would then be the "odd one out" but perhaps there's a good reason? >>> >>> No, array-map should be the same too. >> >> -- >> 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 -- 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
