Luc, On Sat, Oct 22, 2011 at 3:40 PM, Luc Prefontaine < lprefonta...@softaddicts.ca> wrote:
> 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. > The contract is required for implementing any kind of hash map anywhere. This is not Java or the JVM influencing Clojure to do something it wouldn't have otherwise. The references were examples to show that widely varied languages/platforms agree: if you want to implement a hash map in any language on any platform, then when two objects are equal their hashCodes should be equal. I'm fine with changing the Java semantics with respect to Integer and Long equality, BUT if we're going to change equality, then the hashing function has to be congruent with that equality function. If equals and hashCode are not congruent, on any platform, in any language, anywhere, then you do not have a hash map, you have a broken hash map. You can see the brokenness in the example code I posted. > Clojure prefers to avoid having different rules than Java regarding number > handling ? Be so, it's legitimate. > I'm not arguing against that. I'm saying make the equality different, BUT you also have to make the hashCode function congruent. 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. > I mean, again, I don't understand why you're saying this. I agree interop needs to exist and to be at a low level. The question is, given that some form of interop must exist, how should it work? Right. The discussion that we're having here is about how Java interop should work. I don't think it makes sense to come in and say, that we can't let Java and the JVM influence how we interop with Java and the JVM. Perhaps you are misunderstanding me, or I you. I'm saying given that there must be some form of interop, it does not make sense to box ints as Longs. And the decision to box them as Integers instead should not have any effect on the semantics of anything. Two objections have been raised against boxing ints as Integers so far: 1) it breaks Clojure's collections, and 2) it would have bad effects on the new faster primitive maths. I'm saying: 1) Clojure's PersistentHashMap is broken because it is using incongruent equals and hashCode methods, auto-promoting ints to Longs only hides this, and if you explicitly create an Integer (or get one from Java) PersistentHashMap will still behave badly. Promoting ints to Longs only masks the issue. 2) autoboxing ints to Integers would not have any bad effects on the new faster primitive maths. And as a third point, ints being boxed to Longs stands out as inconsistent with the way all the other primitive integer types are handled. 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
