On Sat, Oct 22, 2011 at 5:51 PM, Stuart Halloway <stuart.hallo...@gmail.com>wrote:
> I am dropping off this thread now. At this point I think it would be more > useful for me (or someone) to expand the notes about numerics into better > documentation, rather than continuing this rambling point-by-point treatment > without getting all of the considerations into play at once. I hope to get > that done by conj. So you are still thinking that the current behavior is OK and just needs to be documented better? Or are you saying that we need to collect the various pros and cons to decide whether the current behavior should change or remain the same? Having reviewed the thread there is lots of confusion, but from the points made it seems clear to me that the behavior should change. CON (The "we should box ints as Longs" (or "we should keep things as they are") camp): 1) If we box ints as Integers it will break Clojure's collections (Stu Halloway) 2) Boxing ints as Integers would make Clojure's design inconsistent (David Nolen) 3) Clojure now only has 64-bit primitives (David Nolen/Kevin Downey) 4) If 32-bit ints are allowed to exist, the Clojure's numeric operators would have to handle them (David Nolen) CON1 is a bug in PersistentHashMap, and I opened a Jira bug for it ( http://dev.clojure.org/jira/browse/CLJ-861). CON2 is false. The way primitives are boxed for interop doesn't and shouldn't have any effect on Clojure's design as such. This is a discussion about interop consistency, and if you look at the PRO section you will see Clojure is already inconsistent with respect to interop. Nathan and others are arguing that it should be made consistent. CON3 is false. 32-bit primitives do exist in Clojure (at least Java Clojure), they are just not the optimized case. They may get immediately converted to longs or boxed in some way, but we cannot deny their existence, especially around interop. CON4 Again, 32-bit integers do exist, and are already handled by the numeric operators. When you compile a function with primitive args, Clojure also generates a method that takes Objects. If you pass in anything other than a long it gets boxed, cast to a java.lang.Number, has its longValue method called, and that value gets passed to the primitive arg version. This is slow (as expected) because you are not using the optimized case (64-bit primitives). Absolutely none of that would have to change/get slower because ints were boxed as Integers instead of Longs. I think the problem with all of these CONs is that they confuse boxing for interop with either a bug in PersistentHashMap, or fast primitive maths, and neither of those has anything to do with how ints are boxed. PRO (The "we should box ints as Integers" camp): 1) Clojure is inconsistent in how it boxes primitive data (Chris Perkins) Clojure 1.3: (class (Long/parseLong "1")) => java.lang.Long (class (Integer/parseInt "1")) => java.lang.Long (class (Short/parseShort "1")) => java.lang.Short (class (Byte/parseByte "1")) => java.lang.Byte (class (Float/parseFloat "1")) => java.lang.Float (class (Double/parseDouble "1")) => java.lang.Double 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
