On Sunday, October 23, 2011 5:21:52 PM UTC-4, Rich Hickey wrote:
Hi all,
This reply is to the thread, not Luc specifically.
Thanks everyone for your feedback and input.
I have pushed 3 commits:
1) Fixes the inconsistency between the hash function used by Clojure maps
(was .hashCode)
How can people toggle between the various commits I mentioned using Maven?
Rich
On Oct 23, 2011, at 9:52 PM, Stuart Sierra wrote:
As a reminder, you don't need Git to use the latest development version of
Clojure. Just set your Clojure dependency version to 1.4.0-master-SNAPSHOT
and add
;; lein for all 3 commits
[org.clojure/clojure 1.4.0-master-20111023.210239-5]
and I imagine you can do something similar with maven, the main thing
is you need to add the sonatype snapshot repo.
but you can't access individual commits because the build machine
polls and gathers the latest
You can't jump around at a per-commit level (unless there's one build for
each commit) but you can jump around among individual builds.
You can see a list of all completed builds on our Hudson server:
http://build.clojure.org/view/Clojure/job/clojure/
The module builds pages show the Git commit
On Sat, Oct 22, 2011 at 7:53 PM, Luc Prefontaine
lprefonta...@softaddicts.ca wrote:
Ha ! Ok, I missed the digression here and I now understand the issue.
Considering that a PersistentArrayMap may eventually become a
PersistentHashMap
this opens the door to *funny* bugs.
Is this the only
On Sat, Oct 22, 2011 at 5:51 PM, Stuart Halloway
stuart.hallo...@gmail.comwrote:
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
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
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
On Sun, 23 Oct 2011 20:31:51 +0200
Ivan Koblik ivankob...@gmail.com wrote:
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
On Sun, Oct 23, 2011 at 4:01 PM, Luc Prefontaine
lprefonta...@softaddicts.ca wrote:
It's simpler to use one representation to port the core. You can choose the
fastest/efficient one. You do not have to carry all these intermediate
types
with you.
There are already at least two numeric
Hi all,
This reply is to the thread, not Luc specifically.
Thanks everyone for your feedback and input.
I have pushed 3 commits:
1) Fixes the inconsistency between the hash function used by Clojure maps (was
.hashCode) and =. Thanks Paul for the report.
2) Changes core/hash to return the
As a reminder, you don't need Git to use the latest development version of
Clojure. Just set your Clojure dependency version to 1.4.0-master-SNAPSHOT
and add Sonatype to your Maven repositories.
Detailed instructions here:
http://dev.clojure.org/display/doc/Maven+Settings+and+Repositories
On Wednesday, October 19, 2011 10:38:56 AM UTC-4, stuart@gmail.com
wrote:
Integers and longs are going to be painful no matter what because they are
broken in Java, e.g.
It is incorrect to say that Integers and longs...are broken in Java.
user= (.hashCode (Integer. -1))
-1
user= (.hashCode
If Clojure's primary objective were Java interop, I might agree with you.
However, it's not, and it's bizarre to see someone argue that this is not
broken:
user= (.equals (Integer. -1) (Long. -1))
false
Sure, not broken according to the Java object model and its equality semantics,
but damn
On Sat, Oct 22, 2011 at 9:48 AM, Chas Emerick cemer...@snowtide.com wrote:
If Clojure's primary objective were Java interop, I might agree with you.
However, it's not, and it's bizarre to see someone argue that this is not
broken:
user= (.equals (Integer. -1) (Long. -1))
false
Sure, not
Java != JVM.
That's a too common mistake. Integer vs Long, Byte, ... are Java creations.
They have nothing to do with the JVM primitive data types.
Clojure implements a semantic different than Java on top of the JVM, why not ?
That's the whole idea of having the JVM around. Abstracting the
On Sat, Oct 22, 2011 at 1:49 PM, Luc Prefontaine
lprefonta...@softaddicts.ca wrote:
Java != JVM.
That's a too common mistake. Integer vs Long, Byte, ... are Java creations.
They have nothing to do with the JVM primitive data types.
Clojure implements a semantic different than Java on top
a) Clojure does not to implement Integer, Byte, ... or any of the number
related Java classes.
It uses native JVM data types. The Integer class has nothing to do with the
JVM primitive types.
These are Java concepts. It has nothing to do with Clojure itself. It's
alien stuff.
Dunno
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
The contract in Clojure is clear, they are only long integer values except if
you cast
them accordingly for Java interop purposes. Anything else is a long so there
are no
contract breaches.
It's not a platform issue, it's a Java issue. Equality is implemented by Java
for objects.
It has
On Saturday, October 22, 2011 4:31:29 PM UTC-4, Luc wrote:
Where's the contract breach here ?
Glad you asked. Consider the following clojure session (1.3), shortened for
your reading pleasure:
map-1 = {-1 :yo}
map-2 = {-1 :yo}
key-1 = -1
key-2 = -1
Just some simple maps and values,
Your example is so short that I cannot replicate it:
user= (def a (hash-map -1 :a))
#'user/a
user= (def b (array-map -1 :a))
#'user/b
user= (= a b)
true
user= (= (key (first a)) (key (first b)) -1)
true
I said to myself, Ok he's been throwing some ints in there:
user= (def a (hash-map (int -1)
Note that I'm not claiming to have any deep insights into what's broken and
what's not, either in Clojure or in Java. All I'm saying is that claiming
anything along the lines of Clojure is not Java, so we can do whatever we
want - contracts do not apply does not lead to sane map behavior.
On Sat, Oct 22, 2011 at 5:42 PM, Luc Prefontaine
lprefonta...@softaddicts.ca wrote:
What's missing from your shortened example ?
I think what you want is the example I posted originally:
user= (get {(Long. -1) :here} (Integer. -1))
:here
That works fine because you are actually creating an
Ha ! Ok, I missed the digression here and I now understand the issue.
Considering that a PersistentArrayMap may eventually become a PersistentHashMap
this opens the door to *funny* bugs.
Is this the only known case ?
Luc
On Sat, 22 Oct 2011 18:55:52 -0400
Paul Stadig p...@stadig.name 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
On Fri, Oct 21, 2011 at 12:52 AM, nathanmarz nathan.m...@gmail.com wrote:
user= (class (Integer/parseInt 1))
java.lang.Long
(Integer/parseInt 1) returns an int - which Clojure promotes to long
(since it only has 64-bit primitives) and class takes an Object so
long is boxed to Long.
user=
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
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
Perhaps I can clarify why the 1.3 behavior is confusing. For those who have
focused on issues like primitives need to be boxed, therefore you get a
long - I think you are missing Nathan's point. Here is what changed about
boxing in 1.3:
Clojure 1.2:
(class (Long/parseLong 1)) =
Yea let's chat on IRC. I'll ping you when I see you online.
-Nathan
On Oct 21, 4:24 am, Stuart Halloway stuart.hallo...@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
Yes, I understand the behavior perfectly well. The primitive int gets
converted to a Long immediately, as this code demonstrates:
user= (class (Integer/parseInt 5))
java.lang.Long
The int isn't being boxed into a Long -- the type is being changed.
I'm aware that I can fix things by converting
Yes, I understand the behavior perfectly well. The primitive int gets
converted to a Long immediately, as this code demonstrates:
user= (class (Integer/parseInt 5))
java.lang.Long
The int isn't being boxed into a Long -- the type is being changed.
I'm aware that I can fix things by
We still have a sizable Java chunk here closely interacting with Clojure
and fully agree with #1 and #2.
Interop is environment specific and should not be driving the Clojure language
design.
Otherwise Clojure generics would have to bend to Java, CLR, JS and future
implementations in
other
On Thu, Oct 20, 2011 at 1:54 AM, nathanmarz nathan.m...@gmail.com wrote:
Yes, I understand the behavior perfectly well. The primitive int gets
converted to a Long immediately, as this code demonstrates:
user= (class (Integer/parseInt 5))
java.lang.Long
class is a clojure function that takes
Here's a quick proof using an interface-based primitive detector:
(definterface IPrimitiveTester
(getType [^int x])
(getType [^long x])
;; other types elided
)
(deftype PrimitiveTester []
IPrimitiveTester
(getType [this ^int x] :int)
(getType [this ^long x] :long)
;; other types
Oops, I elided a little too much. Need a method with an Object signature to
distinguish Integer from int:
(definterface IPrimitiveTester
(getType [^int x])
(getType [^long x])
;; etc
(getType [^Object x]))
(deftype PrimitiveTester []
IPrimitiveTester
(getType [this ^int x] :int)
Thanks, that clarifies the behavior. Regardless though, at some point
the int is becoming a Long which is a change of type. I'm arguing
that Clojure should box primitive ints as Longs.
Stu, I wouldn't say Clojure's behavior makes it just work. For
example, if I obtained by number using
Oops, I meant Clojure should box primitive ints as Integers. :-)
On Oct 20, 12:15 pm, nathanmarz nathan.m...@gmail.com wrote:
Thanks, that clarifies the behavior. Regardless though, at some point
the int is becoming a Long which is a change of type. I'm arguing
that Clojure should box
Such a change would be make Clojure's numeric design inconsistent. You keep
saying that Clojure is changing the types - that's probably not the right
way to look at it.
It's a semantic change, Clojure now only has 64bit primitives - the same way
that JavaScript only has doubles.
Prior to the 1.3
But Clojure is already inconsistent. ints and Integers in interop are
treated differently. The only way to make Clojure consistent is to
either:
1. Box ints as Integers
2. Always convert Integers to Longs.
I'm not sure on the feasibility of #2.
I'm not trying to be obtuse, but I really don't
On Thu, Oct 20, 2011 at 3:45 PM, nathanmarz nathan.m...@gmail.com wrote:
But Clojure is already inconsistent. ints and Integers in interop are
treated differently. The only way to make Clojure consistent is to
either:
Clojure is consistent. Whether or not that makes *interop* easier or
On Thu, Oct 20, 2011 at 12:45 PM, nathanmarz nathan.m...@gmail.com wrote:
But Clojure is already inconsistent. ints and Integers in interop are
treated differently. The only way to make Clojure consistent is to
either:
as David said Clojure now only has 64bit primitives.
an Integer is not a
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
On Thu, Oct 20, 2011 at 1:11 PM, nathanmarz nathan.m...@gmail.com wrote:
of contention is what Clojure does when it has to box a primitive int.
My understanding is that Clojure 1.3 has 64-bit primitives, i.e.,
longs and double. You only have a primitive int if you coerce the
value to int (for an
So you propose this:
user= (time (dotimes [i 1000] (let [ a (Integer. 1) b (Integer. 2)] (+ a
b
Elapsed time: 31.14886 msecs
nil
Instead of this:
user= (time (dotimes [i 1000] (let [ a 1 b 2] (+ a b
Elapsed time: 15.680386 msecs
nil
Using a wrapper instead of a primitive type
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
It is a Long object. Vars hold objects, so it has to be boxed.
However, if instead of def'ing it you immediately called some java
method that will accept either a primitive int or a primitive long, my
understanding is that Clojure would arrange for the int version to be
called, because no boxing
Thanks Alan, that makes sense. This code example illustrates that
Clojure values can already be primitive ints:
user= (let [i 1] (primitive-type i))
:long
user= (let [i (Integer/parseInt 1)] (primitive-type i))
:int
So it appears that Clojure's behavior is case #2 from my last comment.
All I'm
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=
Thanks. I read through that and it didn't quite answer my question. To
me it seems more logical that:
1. Clojure defaults to longs when you create a new number (with a
literal 0, 1, etc)
2. You can create ints by doing (int 0)
3. Clojure never changes the types of things you're using
I
Here's a code example illustrating the problem I'm having:
https://gist.github.com/1300034 I've simplified it to the bare minimum
necessary to illustrate the problem.
Agree 100% that ints and longs are broken in Java. The hashcode/
equality stuff is messed up. Clojure can try really hard to hide
On Wed, Oct 19, 2011 at 5:14 PM, nathanmarz nathan.m...@gmail.com wrote:
Here's a code example illustrating the problem I'm having:
https://gist.github.com/1300034 I've simplified it to the bare minimum
necessary to illustrate the problem.
Agree 100% that ints and longs are broken in Java.
Hey all,
I recently started upgrading Storm to Clojure 1.3, and I ran into
various issues due to Clojure's treatment of integers and longs. In
particular, I have a situation like the following:
1. A Java object returns me an int. Let's call this value v.
2. I put v into a map, and pass that map
233 messages long thread from June 2010,
http://groups.google.com/group/clojure/browse_thread/thread/c8c850595c91cc11/171cacba292a0583
David
On Tue, Oct 18, 2011 at 5:00 PM, nathanmarz nathan.m...@gmail.com wrote:
Hey all,
I recently started upgrading Storm to Clojure 1.3, and I ran into
Thanks. I read through that and it didn't quite answer my question. To
me it seems more logical that:
1. Clojure defaults to longs when you create a new number (with a
literal 0, 1, etc)
2. You can create ints by doing (int 0)
3. Clojure never changes the types of things you're using
I find
On Tue, Oct 18, 2011 at 7:45 PM, nathanmarz nathan.m...@gmail.com wrote:
Thanks. I read through that and it didn't quite answer my question. To
me it seems more logical that:
1. Clojure defaults to longs when you create a new number (with a
literal 0, 1, etc)
2. You can create ints by doing
57 matches
Mail list logo
