Hello Luc, In all fairness I don't see how converting ints to Integers returned by class methods would break the abstraction. If you start talking about portability of Clojure code, then Long is as portable as Integer is. (In general they are not.)
Could you explain your position on the fact that shorts get converted to Short? Why is it not possible to do the same for ints? I don't think that there was anyone in this thread that would suggest keeping 32bit math in Clojure. For what it's worth, Integer can be converted to Long first time it is used in any computation. Cheers, Ivan. On 23 October 2011 17:16, Luc Prefontaine <lprefonta...@softaddicts.ca>wrote: > CON1 - I'm buying your argumentation about consistency in Clojure maps and > fixing them. Integer OBJECTS (as opposed to int primitive) should be > handle as objects consistenly, not as primitive values promoted to long. > > CON2, CON3 and CON4 - No way, the current design choice is the good one. > > So many languages have been plagued with numbers of different sizes/formats > for ints and floating point values, > it's not a direction that Clojure should follow. > These distinct types are source of many problems (overflow handling, > precision problems, ...). > > The need for Clojure to support these things is similar to calling > assembler > from C. You matter about bytes, shorts and similar things at the frontier, > when it's time to call a low level service, you need to be able to pass > these values. > > By no means this implies that you have to support them in your language > runtime. > It complects (;) everything including computations and makes your runtime > much more harder to port. > > It's an interop centric thing and interop is by essence not portable. > It does not belong to the core of Clojure. It's better to rely on cast > operators > to call interop than to expect Clojure to box numeric values according to > some interop > convention that may vary according to the platform Clojure runs on. > > Luc P. > > On Sun, 23 Oct 2011 07:19:41 -0400 > Paul Stadig <p...@stadig.name> wrote: > > > 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 > > > > > > -- > 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 > -- 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
