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
