Like Stu says, this conversation is going in circle. "Concrete code examples" cannot be a replacement for consistent rules when designing software and especially a prog. language.
Since the beginning of this thread, you have been exposed to two of these: a) make collections consistent b) make computations efficient in Clojure These are 2 major reasons why promoting to long is rational. No need for code snippets. "Intuitive" is relative, it's not an objective criteria. What may seem intuitive to you can be counter intuitive to others. It all depends on the background of individuals. If you know the rules relative to numerics in Clojure and why they have been chosen, then its perfectly rational. Read carefully: http://dev.clojure.org/display/doc/Documentation+for+1.3+Numerics They is nothing else to say about this subject. Luc On Fri, 21 Oct 2011 00:52:50 -0700 (PDT) nathanmarz <nathan.m...@gmail.com> wrote: > Luc, what you're saying sounds to me like "this is the way it is so > deal with it". Can you give me some concrete code snippets showing why > it's better to box ints as Longs? Do you really think the following is > at all intuitive? > > user=> (class (Integer/parseInt "1")) > java.lang.Long > user=> (class (Integer/valueOf "1")) > java.lang.Integer > > > -Nathan > > > > On Oct 20, 10:27 pm, Luc Prefontaine <lprefonta...@softaddicts.ca> > wrote: > > The "weirdness" here is that you seem to confuse the Java context > > and the Clojure context. They are not the same. Clojure has to > > satisfy to performance and consistency criterias. It's a language > > of it's own, not a Java offspring. > > > > user=> (class (Integer/parseInt "1")) > > java.lang.Long > > user=> > > > > Integer/parseInt returns a primitive type. Not a boxed Integer > > object. If used as a key in a map or anything else in Clojure, it > > will get promoted to a long value as per the math promotion rules > > (long/double representation). Obviously needed if it is to be used > > later in a computation otherwise it would break math operations > > consistency by allowing mixed int/long operands. > > > > If passed as an interop parameter it will retain it's int type. > > > > user=> (class (Integer/valueOf 1)) > > java.lang.Integer > > > > Integer/valueOf returns an Integer object, not a primitive type. > > It's an object, not a primitive type, Clojure will not change it. > > If used as a key in a Clojure map or any Clojure data structure, it > > will retain its object status. > > > > Just cast your keys accordingly if you want Integer objects as keys. > > In your short example, 1 as a key will not do it, it gets promoted > > to primitive long. > > > > You may not recall but in Java, int used not to be compatible with > > Integer objects. It's only since java 5 that you can assign an > > Integer object to a primitive int. That's the compiler tricking > > things to allow you to do that. In the JVM there's still not > > represented in the same way. > > > > The above Integer member functions and their behavior have nothing > > to do with Clojure. They result from bad decisions made years ago > > when designing Java and the JVM and you are blaming Clojure for not > > handling them according to some patch implemented afterward in the > > Java compiler. > > > > You ran in the ClassCast exception by yourself. Clojure did not > > push you into it. When using Java interop you have to obey to Java > > rules and bend accordingly. It's not Clojure that needs to bend, > > it's you to adapt to the interop restrictions/conventions. > > > > If Java expects an Integer object somewhere make sure you are > > providing it. > > > > Luc P. > > > > On Thu, 20 Oct 2011 21:11:41 -0700 (PDT) > > > > > > > > > > > > > > > > > > > > nathanmarz <nathan.m...@gmail.com> wrote: > > > Now I'm confused. So when I do this: > > > > > (def i (Integer/parseInt "1")) > > > > > Is "i" a primitive int, a primitive long, or a Long object? > > > > > I was under the impression that it was a primitive int based on > > > Justin's test code, but when I run "(primitive-type i)" in the > > > REPL it tells me :object. > > > > > If "i" is a primitive int, then the only change I'm proposing is > > > that if Clojure needs to box that value later on, that it box it > > > as an Integer instead of a Long. This change in behavior would > > > not affect primitive number performance since it's at a point > > > when Clojure is already boxing. > > > > > If "i" is a primitive long (which is what I thought was happening > > > originally), I propose that Clojure box the value as an Integer > > > unless you wrap the form in a "(long ...") form. In the latter > > > case Clojure would do what it's doing currently so you can still > > > get the performance if you need it. The difference is that you're > > > being explicit about the type changing so there's no possible > > > confusion in that regard. > > > > > Finally, if "i" is a Long object, I propose that it instead be > > > boxed as an Integer object. > > > > > Note that I am not saying: > > > > > 1. That Clojure always box primitives into an object form > > > 2. That Clojure implement 32 bit arithmetic > > > > > In all these cases, you can still get maximum performance without > > > Clojure changing ints to longs. Please correct me if there's > > > something I'm missing here. > > > > > Stu's argument from above is that Clojure boxes ints to Longs > > > instead of Integer to avoid weirdness with hashcode/equality in > > > collections. This is a reasonable point, but consider this code > > > example: > > > > > user=> (def m1 {(Integer/valueOf "1") 2}) > > > #'user/m1 > > > user=> (def m2 {(Integer/parseInt "1") 2}) > > > #'user/m2 > > > user=> (map class (keys m1)) > > > (java.lang.Integer) > > > user=> (map class (keys m2)) > > > (java.lang.Long) > > > > > Clojure doesn't prevent you from putting Integer objects in > > > collections. So there are cases where you still need to do type > > > coercion yourself. Given that Clojure can't hide this problem > > > completely from you, I think it's better that it treat "int" and > > > "Integer" consistently by boxing ints as Integers. Then there's no > > > weirdness like I ran into with getting ClassCastExceptions > > > because the type changed. > > > > > -Nathan > > > > > On Oct 20, 6:19 pm, David Nolen <dnolen.li...@gmail.com> wrote: > > > > On Thu, Oct 20, 2011 at 4:11 PM, nathanmarz > > > > <nathan.m...@gmail.com> wrote: > > > > > I'm not sure we're arguing about the same thing. I think that > > > > > Clojure only supporting 64 bit primitive arithmetic is fine, > > > > > and I'm not proposing that it support 32 bit primitive > > > > > arithmetic. The sole point of contention is what Clojure does > > > > > when it has to box a primitive int. I think this is > > > > > orthogonal to primitive args/return, but correct me if I'm > > > > > wrong. > > > > > > If 32bit ints are allowed to exist then the various numeric > > > > operators must handle them. If the numeric operators handle them > > > > then primitive arg and return should probably be supported. But > > > > that would exponentially increase the number of interfaces > > > > required for primitive arg return support. > > > > > > David > > > > -- > > Luc P. > > > > ================ > > The rabid Muppet > -- 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
