On Sat, Oct 22, 2011 at 1:49 PM, Luc Prefontaine < lprefonta...@softaddicts.ca> wrote:
> > Java != JVM. > > That's a too common mistake. Integer vs Long, Byte, ... are Java creations. > They have nothing to do with the JVM primitive data types. > > Clojure implements a semantic different than Java on top of the JVM, why > not ? > That's the whole idea of having the JVM around. Abstracting the metal. > > Clojure reuses Java strings as is but it could have implemented its own on > top of the > char primitive type at the expense of less transparent interop. This is an > implementation choice. > It does not tie Clojure to Java. > Um...I guess I don't understand how what you're saying is relevant. Are you saying that Clojure should implement it's own Byte, Short, Integer, and Long? If you are, then the hashCode contract should be obeyed. If you're not, then it's fine for PersistentHashMap to redefine equals for java.lang.{Byte,Short,Integer,Long}, but hashCode should also be redefined. The hashCode contract is not a Java thing, it is a JVM thing, and in fact (as I mentioned before) it is a mathematical contract that you must obey to implement a hash table in any language and on any platform. Python has a similar contract http://docs.python.org/reference/datamodel.html#object.__hash__ C# has a similar contract http://msdn.microsoft.com/en-us/library/system.object.gethashcode.aspx Common Lisp has a similar contract http://www.lispworks.com/documentation/HyperSpec/Body/f_sxhash.htm#sxhash The brokenness of PersistentHashMap with respect to the hashCode problem has nothing to do with Java (or even the JVM). > These are Clojure centric decisions. Lets get out Java out of this > discussion. > Clojure is not Java and even if it provides a "soft" bridge > to reuse Java code, its feature set is certainly not Java centric. > > A Clojure persistent map is a ... Clojure data structure, not a Java data > structure. > Interfaces like java.util.Map have nothing to do with the content of the > map itself. > If they help make interop calls smoother fine. But do not tie their Java > semantic to > the Clojure semantic. It's unrelated outside of the interop domain. > > I do not care about Java centric stuff. I adopted Clojure to get away from > Java > ASAP. > The reality is that PersistentHashMap does implement j.u.Map, and as much as possible Clojure tries to live at peace with other classes/objects on the JVM. There will always be some level of interop and semantics that must be matched with the platform. If you want to totally avoid Java, then I don't think Clojure is going to help you. It's not just a coincidence that Clojure strings are java.lang.Strings, and there are probably many people who would not have found Clojure as compelling if it didn't have a great interop story, and the ability to access a huge set of existing libraries. I feel like this is drifting off topic though. Coming back to the original issues: 1) PersistentHashMap should be using a hashing function that is congruent with the equals function it uses. 2) Boxing ints as Longs sticks out when every other primitive is boxed into its java.lang.* equivalent. 3) Boxing ints as Integers would not have any adverse effect on the improvements to primitive maths. I'd be glad to help out with any of this. Paul -- 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