a) Clojure does not to implement Integer, Byte, ... or any of the number
related Java classes.
It uses native JVM data types. The Integer class has nothing to do with the
JVM primitive types.
These are Java concepts. It has nothing to do with Clojure itself. It's
alien stuff.
Dunno why you insists on these. Clojure has not been designed to be a Java
superset.
It's a language of its own.
b) The way Java interprets equality based on the hash code is a Java specific
behavior.
It's defined by the Java API.
There's nothing in the jvm spec that defines how a hash code should be used.
It's a reference.
Nothing more.
All the contracts you mention are language centric, each of them defined their
contract according
to their own needs. Clojure should have the right to do so.
Clojure prefers to avoid having different rules than Java regarding number
handling ? Be so, it's legitimate.
If people like you were free to take these decisions we would end up with three
different languages, one on the
jvm, one on CLR and one on JS. Nonsense. Having to deal with three different
interops and trying to
unify them a bit is enough work by itself.
Interop stuff is low level and should remain there. If a single interop
implementation starts to influence
the Clojure language and result in such short term and narrow scope decisions,
we will all have a problem
in the future.
Luc P.
On Sat, 22 Oct 2011 15:04:33 -0400
Paul Stadig <p...@stadig.name> wrote:
> 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
>
--
Luc P.
================
The rabid Muppet
--
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
