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
--
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
