Re: Is there a reader setting support BigDecimal by default?
On Tue, Oct 18, 2011 at 3:47 PM, Tassilo Horn wrote: > Scott Hickey writes: > And usually, you should refrain from using floating points at all, no > matter if BigDecimal or Double. I thought BigDecimal with was not a floating point in the traditional sense (ie., subject to all of the usual rounding horror, unless you ask it to be)? That is, you can do decimal calculations exactly using it. -- [what were the skies like when you were young?] -- 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
Re: Clojure 1.3 treatment of integers and longs
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 the type back to an
Integer manually, but that's not the point. Changing the types is
unusual behavior that leads to hard to track down bugs like I ran into
with the ClassCastException. My proposal still stands.
-Nathan
On Oct 19, 5:29 pm, Kevin Downey wrote:
> On Wed, Oct 19, 2011 at 5:14 PM, nathanmarz wrote:
> > Here's a code example illustrating the problem I'm having:
> >https://gist.github.com/1300034I'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 this,
> > but it can't hide it completely since Java libraries can always return
> > you Integer objects. The additional complexity added from changing the
>
> Existing Integer objects are unchanged. If the method call in your
> example did return an Integer object then you would never notice
> anything.
>
> > types on you isn't worth it IMO.
>
> > Here's my proposal for what I think would be better behavior:
>
> > 1. Clojure boxes ints into Integers rather than convert them into
> > longs
>
> clojure does not convert ints into longs, you are putting a primitive
> into a collection, which requires boxing, clojure 1.3 boxes ints as
> Longs. If you put (Integer. …) around your call you will be fine.
>
>
>
>
>
>
>
>
>
> > 2. If you wrap the form in "(long ...)", Clojure skips the boxing and
> > does what it does now. Since this is done explicitly, there's no
> > confusion about types.
>
> > -Nathan
>
> > On Oct 19, 7:38 am, Stuart Halloway 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 (int 0)
> >> > 3. Clojure never changes the types of things you're using
>
> >> > I find Clojure's behavior of changing the types of primitive ints to
> >> > longs highly unusual, and it is causing a lot of pain in upgrading
> >> > Storm to 1.3.
>
> >> Integers and longs are going to be painful no matter what because they are
> >> broken in Java, e.g.
>
> >> Object[] objects = new Object[] {-1, -1L};
> >> System.out.println(objects[0].hashCode());
> >> System.out.println(objects[1].hashCode());
>
> >> Clojure avoids this pit by standardizing on longs, which leaves you with
> >> the need to specifically request ints when you need them for interop. You
> >> can use (int n) hints to select the correct interop method invocation, or
> >> box an int if you want to hold on to a value guaranteed to be int.
>
> >> Can you post a code example that shows a problem you are having?
>
> >> Stu
>
> >> Stuart Halloway
> >> Clojure/corehttp://clojure.com
>
> > --
> > 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
>
> --
> And what is good, Phaedrus,
> And what is not good—
> Need we ask anyone to tell us these things?
--
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
Re: Is there a reader setting support BigDecimal by default?
On Thu, Oct 20, 2011 at 11:17, Joel Gluth wrote: > On Tue, Oct 18, 2011 at 3:47 PM, Tassilo Horn wrote: >> Scott Hickey writes: >> And usually, you should refrain from using floating points at all, no >> matter if BigDecimal or Double. > > I thought BigDecimal with was not a floating point in the traditional > sense (ie., subject to all of the usual rounding horror, unless you > ask it to be)? That is, you can do decimal calculations exactly using > it. The term "floating" point is used to distingiush from fixed-point schemes, such as deciding that We're going to store money as a 64 bit integer representing the number of 100ths of a cent. Effectively, fixing the decimal point thus: $1000.. BigDecimal is an arbitrary precision integer and a scale factor (think of the scale factor as multiplying or dividing by a power of ten.) So, in that sense the (decimal) point floats. Unlike "floating point" in the IEEE754 sense, BigDecimal is decimal, not binary, (so e.g. 0.1 has a terminating representation) and arbitrary precision, so you can avoid rounding effects unless you're dividing where you might have to round to truncate a non-terminating representation. // Ben -- 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
Re: About metadat and #^ macro.
Alan, I'm with you on this one. Reflection is so much slower that sometimes I wish clojure had a different syntax for reflective method invocation. For example: 1) Make reflection an automatic error (not even a warning), and 2) Use another syntax (let's say double-dot, for the sake of argument) to mean "I'm OK with this being done via reflection." (.foo bar) => error (.foo ^SomeType bar) => fast (..foo bar) => probably slow Of course, something this fundamental is unlikely to change, so I guess I should just get used to setting *warn-on-reflection* :) - Chris -- 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
Re: Is there a reader setting support BigDecimal by default?
Joel Gluth writes: >> And usually, you should refrain from using floating points at all, no >> matter if BigDecimal or Double. > > I thought BigDecimal with was not a floating point in the traditional > sense (ie., subject to all of the usual rounding horror, unless you > ask it to be)? That is, you can do decimal calculations exactly using > it. You are right. What I've meant that you don't want to use double or float because it's not precise, and you don't want to use BigDecimal because it's slower and, even more important, it'll throw an exception if a given number cannot be represented as decimal number. user=> (/ 1M 3) ArithmeticException Non-terminating decimal expansion; no exact representable decimal result. java.math.BigDecimal.divide (BigDecimal.java:1616) So the general suggestion is to stick to integers and rational numbers as long as possible. Bye, Tassilo -- 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
Re: About metadat and #^ macro.
On Thu, Oct 20, 2011 at 3:53 PM, Chris Perkins wrote: > 1) Make reflection an automatic error (not even a warning), and > 2) Use another syntax (let's say double-dot, for the sake of argument) to > mean "I'm OK with this being done via reflection." > (.foo bar) => error > (.foo ^SomeType bar) => fast > (..foo bar) => probably slow Instead of introducing a whole new (possibly confusing) syntax for reflective calls, IMHO it's better to have a var *error-on-reflection* which, when set to true will throw an error on reflection. A patch for this should be easy to implement as well. Regards, BG -- Baishampayan Ghose b.ghose at gmail.com -- 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
Re: Type hints and records
Tangentially: In this particular case, reflection isn't strictly necessary because toString is a method of Object. In theory, the compiler could special-case Object's methods and never do reflection, right? In practice, I don't know if it's worth the effort, although it's certainly a little surprising that (.toString thing) can be 100 times slower than (str thing), at least until you know what's going on there. - Chris -- 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
clojure starter package for aichallenge ?
hi clojure community, at the moment there seems to be no applicable clojure starter package for the http://aichallenge.org/ though some work has be done on it by chris granger, i think: https://github.com/ibdknox/aichallenge are there any plans to get a clojure starter package out ? it would be nice to see clojure-programs participate in the challenge. have a successful day -- 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
Array type hints in 1.3
Hi, definterface has the ability to type methods. http://dev.clojure.org/jira/browse/CLJ-737 and its attached patch http://dev.clojure.org/jira/secure/attachment/10119/definterface-array-fix-with-tests.patch suggest, that you should be able specify array types too. When I tried it (in 1.3), however, it didn't work: > (definterface Name (^"[Ljava.lang.String;" method [])) Method "method" in class aserver/entity/device/Name has illegal signature "()L[Ljava/lang/String;;" [Thrown class java.lang.ClassFormatError] Primitive array hints do compile, the compiled code refers to a class named by the literal string though; hinting with ^longs, .. works: > (definterface Name (^"[J" method [^longs arg])) // looking into the .class file with JD http://java.decompiler.free.fr/ public abstract [J getPushes(long[] arg); Did I do something wrong? kind regards -- __ Herwig Hochleitner -- 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
Re: Clojure 1.3 treatment of integers and longs
> 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 the type back to an > Integer manually, but that's not the point. Changing the types is > unusual behavior that leads to hard to track down bugs like I ran into > with the ClassCastException. My proposal still stands. > > -Nathan Somebody has to work hard: either users of collections, or interop callers. The current behavior makes things "just work" for collections, at the cost of having to be explicit for some interop scenarios. There are two reasons to favor collection users over interop users: (1) Interop problems are local, and can be resolved by checking the type signature at the point of the problem. Collection key problems are global and break the composability of collections. It is a *huge* benefit of Clojure that collections are sane. (2) There are a lot more lines of code working with collections than doing interop. Stu -- 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
Re: About metadat and #^ macro.
Hey guys, The "small loss of performance expression" was applied to the specific example I used to illustrate the thing. 500 times longer may look huge but if it occurs 10 times in your application run, bottom line it may mean nothing. Of course if you have a fn chewing up 30% of your application run time, reflection may become significant, hence the need to check. It was not meant as a general remark. It's a trade off situation and you must do some analysis to apply these optimizations. Most of the time here we do not care about the type of objects passed except in some frequently reused common code. We do not want to loose the flexibility of dynamic typing, our message bus runs on a small cluster Atom 330 machines 24/7... not Hulk like servers and we should be the rightly concerned by these optimizations. We did not find so many cases that justified retooling the code up to now. Luc P. On Wed, 19 Oct 2011 22:49:46 -0700 (PDT) Alan Malloy wrote: > I agree with the general sentiment: add typehints later, and only if > you need performance in this particular part of the code. I object to > the characterization as a "small loss of performance", though. A > reflective method call takes about five hundred times as long as a > hinted method call in the following benchmark, so if you do have a > performance-sensitive section of your program that needs to do a lot > of interop, the improvement is dramatic, not small. > > user> (time (dotimes [_ 1e6] (let [s (identity "test")] (.length s > "Elapsed time: 15490.471302 msecs" > user> (time (dotimes [_ 1e6] (let [s (identity "test")] (.length > ^String s > "Elapsed time: 34.561754 msecs" > > > On Oct 19, 10:35 pm, Luc Prefontaine > wrote: > > Just use ^ for type hints. > > > > http://clojure.org/java_interop#Java%20Interop-Type%20Hints > > > > Type hints are used to eliminate reflection calls, the compiler can > > use the exact type of the parameter to eliminate the runtime cost > > of finding if methods/fields exist before calling/accessing them. > > > > user=> (set! *warn-on-reflection* true) > > true ;;; <== tells the compiler to complain about reflection calls > > user=> (defn a [b] (.startsWith b "a")) > > Reflection warning, NO_SOURCE_PATH:23 - call to startsWith can't be > > resolved. <=== Oups ! #'user/a > > user=> (a 1) > > java.lang.IllegalArgumentException: No matching method found: > > startsWith for class java.lang.Integer (NO_SOURCE_FILE:0) > > > > This definition has no type hint, the compiler flags a warning to > > say that it cannot resolve the method startsWith. If you try to > > call the first form with an object not implementing startsWith, the > > runtime traps that it did not find the method on that object's > > class. The flexibility comes with a cost, finding the method on the > > fly. > > > > user=> (defn a [^String b] (.startsWith b "a")) > > #'user/a > > user=> (a 1) > > java.lang.ClassCastException: java.lang.Integer cannot be cast to > > java.lang.String (NO_SOURCE_FILE:0) > > > > Here the compilation does not trigger the reflection warning, the > > argument type has been hinted as a string. The compiler can find > > the method immediately and generate the code without any runtime > > "search". > > > > At runtime, if you ever call the second form with a non string > > object, this time you get that the argument type is not the one > > expected (from the type hint). The compiler has added a type check > > instead of relying on the dynamic search for methods/fields in the > > class which is faster. > > > > Note that it's not data typing per se. You are allowed to call the > > form with a different object class. The compiler will not scream, > > the runtime will if you persists to call the method. > > > > Form #1 allows you to pass objects of any class that implements > > startsWith with a small loss of performance. In form #2 you can > > gain performance at the expense of generality. > > > > Type hints are to be to improve performance AFTER your code is more > > or less stable. If you use type hints early in your development, > > you will carry them all the way and that can be a significant pain. > > > > Luc P. > > > > On Wed, 19 Oct 2011 22:03:31 -0700 (PDT) > > > > > > > > > > > > > > > > > > > > mmwaikar wrote: > > > Hi, > > > > > I read in "Clojure in Action" book by Amit Rathore, that #^ > > > associates metadata for the next form. He also mentions that it is > > > deprecated. So what is the current way of doing it? > > > > > Also, in code like this - > > > > > (defn filenames-in-jar > > > "Returns a sequence of Strings naming the non-directory entries in > > > the JAR file." > > > [#^JarFile jar-file] > > > > > is it specifying that the type of the jar-file argument should be > > > JarFile? > > > > > Where can I find some more documentation and or examples about it? > > > > > Thanks, > > > Manoj. > > > > -- > > Luc P. > > > > > > The rabid Muppet > -- Luc P. The ra
Re: Clojure 1.3 treatment of integers and longs
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 environments, loosing its identity along the way and creating a Babel tower. Luc P. On Thu, 20 Oct 2011 09:00:23 -0400 Stuart Halloway 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 > > > > The int isn't being "boxed" into a Long -- the type is being > > changed. > > > > I'm aware that I can "fix" things by converting the type back to an > > Integer manually, but that's not the point. Changing the types is > > unusual behavior that leads to hard to track down bugs like I ran > > into with the ClassCastException. My proposal still stands. > > > > -Nathan > > Somebody has to work hard: either users of collections, or interop > callers. The current behavior makes things "just work" for > collections, at the cost of having to be explicit for some interop > scenarios. > > There are two reasons to favor collection users over interop users: > > (1) Interop problems are local, and can be resolved by checking the > type signature at the point of the problem. Collection key problems > are global and break the composability of collections. It is a *huge* > benefit of Clojure that collections are sane. > > (2) There are a lot more lines of code working with collections than > doing interop. > > Stu > -- 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
Re: Type hints and records
Thanks for the clarification. Just to clear up any confusion, the .toString example was just the simplest example I could think of that illustrated was I was seeing with regards to reflection and type hints :) On Oct 20, 4:22 am, Michael Fogus wrote: > Another potential option is to implement a record toString method: > > (defrecord Rec [^Integer i] > Object > (toString [_] (str i))) > > (str (Rec. 42)) > ;=> "42" -- 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
Rich Hickey: "Simple Made Easy" from Strange Loop 2011
The video is up: http://www.infoq.com/presentations/Simple-Made-Easy Places to watch for comments (or vote if you like): - http://news.ycombinator.com/item?id=3135185 - http://www.reddit.com/r/programming/comments/lirke/simple_made_easy_by_rich_hickey_video/ - http://www.dzone.com/links/simple_made_easy_by_rich_hickey.html -- 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
Re: Clojure 1.3 treatment of integers and longs
On Thu, Oct 20, 2011 at 1:54 AM, nathanmarz 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 Objects, so the int must be boxed.
> The int isn't being "boxed" into a Long -- the type is being changed.
>
> I'm aware that I can "fix" things by converting the type back to an
> Integer manually, but that's not the point. Changing the types is
> unusual behavior that leads to hard to track down bugs like I ran into
> with the ClassCastException. My proposal still stands.
>
> -Nathan
>
>
> On Oct 19, 5:29 pm, Kevin Downey wrote:
>> On Wed, Oct 19, 2011 at 5:14 PM, nathanmarz wrote:
>> > Here's a code example illustrating the problem I'm having:
>> >https://gist.github.com/1300034I'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 this,
>> > but it can't hide it completely since Java libraries can always return
>> > you Integer objects. The additional complexity added from changing the
>>
>> Existing Integer objects are unchanged. If the method call in your
>> example did return an Integer object then you would never notice
>> anything.
>>
>> > types on you isn't worth it IMO.
>>
>> > Here's my proposal for what I think would be better behavior:
>>
>> > 1. Clojure boxes ints into Integers rather than convert them into
>> > longs
>>
>> clojure does not convert ints into longs, you are putting a primitive
>> into a collection, which requires boxing, clojure 1.3 boxes ints as
>> Longs. If you put (Integer. …) around your call you will be fine.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> > 2. If you wrap the form in "(long ...)", Clojure skips the boxing and
>> > does what it does now. Since this is done explicitly, there's no
>> > confusion about types.
>>
>> > -Nathan
>>
>> > On Oct 19, 7:38 am, Stuart Halloway 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 (int 0)
>> >> > 3. Clojure never changes the types of things you're using
>>
>> >> > I find Clojure's behavior of changing the types of primitive ints to
>> >> > longs highly unusual, and it is causing a lot of pain in upgrading
>> >> > Storm to 1.3.
>>
>> >> Integers and longs are going to be painful no matter what because they
>> >> are broken in Java, e.g.
>>
>> >> Object[] objects = new Object[] {-1, -1L};
>> >> System.out.println(objects[0].hashCode());
>> >> System.out.println(objects[1].hashCode());
>>
>> >> Clojure avoids this pit by standardizing on longs, which leaves you with
>> >> the need to specifically request ints when you need them for interop. You
>> >> can use (int n) hints to select the correct interop method invocation, or
>> >> box an int if you want to hold on to a value guaranteed to be int.
>>
>> >> Can you post a code example that shows a problem you are having?
>>
>> >> Stu
>>
>> >> Stuart Halloway
>> >> Clojure/corehttp://clojure.com
>>
>> > --
>> > 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
>>
>> --
>> And what is good, Phaedrus,
>> And what is not good—
>> Need we ask anyone to tell us these things?
>
> --
> 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
--
And what is good, Phaedrus,
And what is not good—
Need we ask anyone to tell us these things?
--
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
Re: Will clojurescript get in-ns and load?
Good point. Let me change the question slightly, Is there a compile time capability that will allow namespaces to be split across several files and merged. Thereby achieving the equivalent of in-ns and load? Basically, I would like to have a namespace where some functions are defined in a different file/location. (The practical use being to allow both jvm and clojurescript implementations of the "same" api) Dave -- 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
Re: Will clojurescript get in-ns and load?
Thinking further, the capability would not be of use (to me) if it were not consistent/indistinguishable across clojure and clojurescript. I have seen in-ns and load used to effectively split a namespace across files If 'in-ns' and 'load' were implemented for clojurescript, could 'load' be managed as a compile time operation to merge the namespaces. Perhaps there are better ways of achieving this that I am not aware of. Cheers D -- 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
Re: Clojure 1.3 treatment of integers and longs
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 elided ) (defmacro primitive-type [x] `(.getType (PrimitiveTester.) ~x)) (comment user=> (primitive-type 5) ;unboxed :long user=> (primitive-type (Integer/parseInt "5")) ;unboxed :int user=> (class (Integer/parseInt "5")) ;boxed java.lang.Long ) Justin -- 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
Re: Clojure 1.3 treatment of integers and longs
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) (getType [this ^long x] :long) ;; etc (getType [this ^Object x] :object)) (defmacro primitive-type [x] `(.getType (PrimitiveTester.) ~x)) (comment user=> (primitive-type (Integer. 5)) :object user=> (primitive-type (Integer/parseInt "5")) :int ) On Thursday, October 20, 2011 1:13:03 PM UTC-4, Justin Kramer wrote: > > 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 elided > ) > > (defmacro primitive-type [x] > `(.getType (PrimitiveTester.) ~x)) > > (comment > > user=> (primitive-type 5) ;unboxed > :long > user=> (primitive-type (Integer/parseInt "5")) ;unboxed > :int > user=> (class (Integer/parseInt "5")) ;boxed > java.lang.Long > > ) > > Justin > -- 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
Clojure 1.3 "wonky" behavior
I recently tried to get Speclj running on Clojure 1.3 and came across the following problem: (list (declare ^:dynamic p) (defn q [] @p)) (binding [p (atom 10)] (q)) > java.lang.ClassCastException: clojure.lang.Var$Unbound cannot be cast to > clojure.lang.IDeref Thanks to @cemerick for helping me condense the snippet, and thanks to both @cemerick and @chouser for the lively discussion on IRC. Yet the discussion was inconclusive. Is the above expected behavior? Micah -- 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
Re: Rich Hickey: "Simple Made Easy" from Strange Loop 2011
In the Simple-Made-Easy talk Rich raises the question of long term use. In particular, he mentions the issue of maintenance and change. In order to change software you need to understand the program. Unfortunately most people equate "understanding the program" as being equivalent to "what the function does". What it also has to mean is "why the function does it". In order to write a program that "lives", that is, one that can be maintained and changed you need to capture why the code exists and why it is written that way. The best solution I have found is called Literate Programming. The LP idea is that you write the program for the programmer rather than the machine. You should be able to sit and read a book that explains the program, including the "why". The real code is in the document but the text explaining the program is the focus. I would encourage you to look at Lisp in Small Pieces. It is a literate program, a book, that contains a complete lisp system with the interpreter and compiler but it is written to be read. Tim Daly "The hardest part of literate programming is the documentation" On Thu, 2011-10-20 at 09:01 -0700, Alex Miller wrote: > The video is up: > > http://www.infoq.com/presentations/Simple-Made-Easy > > Places to watch for comments (or vote if you like): > > - http://news.ycombinator.com/item?id=3135185 > - > http://www.reddit.com/r/programming/comments/lirke/simple_made_easy_by_rich_hickey_video/ > - http://www.dzone.com/links/simple_made_easy_by_rich_hickey.html > -- 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
Question:Multi-Core processor affinity for load balancing Clojure Web apps
This may not be a Clojure specific kind of question, but this is for my Clojure web app(s) so hopefully it's not too far off. Currently when I deploy my web apps I run 1 app instance on 1 app server. Given these are multi-core servers I am thinking about running 4 app instances on a server to get max IO capabilities at a lower cost. (Note that I currently using nginx, to route requests to a Clojure/Ring+Jetty web app on a specified port. I am expecting that in order to run 4 app instances I will need to load balance within nginx to each port and also set the processor affinity for each app instance to ensure they are balanced across cores). So here are my questions: 1. Does this idea make sense? why/whynot? 2. Do you do currently do this for your web apps and can you provide any insight/experiences that could be helpful? 3. Is there a way to specify processor affinity within the application, such that I wouldn't need to manually set them afterwards? 4. Are there better ideas to accomplish the same kind of thing? Thanks for any help/ideas. Tim -- 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
Re: Rich Hickey: "Simple Made Easy" from Strange Loop 2011
As a person currently suffering under the load of a highly entangled system here at work, I really appreciated this talk. The software I'm currently working on is so entangled, so strongly typed, that we have some parts of our app even our Architect doesn't want to touch. It's almost as if Rich looked at our software, then wrote a talk on how not to do what we do here. Iif nothing else, at least my current job is teaching me the value of using Clojure at my next job. So for now, C# at workClojure at home, for everything else, there is beer. Timothy On Thu, Oct 20, 2011 at 1:01 PM, daly wrote: > In the Simple-Made-Easy talk Rich raises the question > of long term use. In particular, he mentions the issue > of maintenance and change. > > In order to change software you need to understand the > program. Unfortunately most people equate "understanding > the program" as being equivalent to "what the function does". > What it also has to mean is "why the function does it". > > In order to write a program that "lives", that is, one > that can be maintained and changed you need to capture > why the code exists and why it is written that way. > > The best solution I have found is called Literate Programming. > The LP idea is that you write the program for the programmer > rather than the machine. You should be able to sit and read > a book that explains the program, including the "why". The > real code is in the document but the text explaining the > program is the focus. > > I would encourage you to look at Lisp in Small Pieces. > It is a literate program, a book, that contains a complete > lisp system with the interpreter and compiler but it is > written to be read. > > Tim Daly > "The hardest part of literate programming is the documentation" > > On Thu, 2011-10-20 at 09:01 -0700, Alex Miller wrote: >> The video is up: >> >> http://www.infoq.com/presentations/Simple-Made-Easy >> >> Places to watch for comments (or vote if you like): >> >> - http://news.ycombinator.com/item?id=3135185 >> - >> http://www.reddit.com/r/programming/comments/lirke/simple_made_easy_by_rich_hickey_video/ >> - http://www.dzone.com/links/simple_made_easy_by_rich_hickey.html >> > > > -- > 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 -- “One of the main causes of the fall of the Roman Empire was that–lacking zero–they had no way to indicate successful termination of their C programs.” (Robert Firth) -- 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
Re: Clojure 1.3 "wonky" behavior
Hi, Am 20.10.2011 um 19:53 schrieb Micah Martin: > I recently tried to get Speclj running on Clojure 1.3 and came across the > following problem: > > (list > (declare ^:dynamic p) > (defn q [] @p)) > > (binding [p (atom 10)] > (q)) > >> java.lang.ClassCastException: clojure.lang.Var$Unbound cannot be cast to >> clojure.lang.IDeref > > Thanks to @cemerick for helping me condense the snippet, and thanks to both > @cemerick and @chouser for the lively discussion on IRC. Yet the discussion > was inconclusive. Is the above expected behavior? I'm not sure. Maybe it's undefined? Clojure compiles per top-level form. In this case this is the call to list. However in p does not exist before. It is created by the def inside this form. And maybe I'm just a weenie, but I wouldn't bet on some not very well documented peculiarities of def. >From the “one top-level form” rule do is an exception. And indeed this seems >to be for a reason: user=> (do (declare ^:dynamic p) (defn q [] @p)) #'user/q user=> (binding [p (atom 10)] (q)) 10 So maybe the rule of thumb is: never reference defs made in the same top-level form unless this form is a do. I'm sorry. I can't explain things further. I suspect that the effect you see is due to some accidental, implementation-dependent behavior of the compiler. Sincerely Meikel -- 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
Re: Clojure 1.3 treatment of integers and longs
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 Integer/valueOf, then Clojure will not change the Integer to a Long and will not prevent me from putting it in a collection. It's confusing that Integer/valueOf will stay an Integer in Clojure-land, and Integer/parseInt will become a Long in Clojure-land. The use case I'm interested in here is just this one point of Java interop: what Clojure does with primitive ints that it gets from a Java object (as far as I can tell, this is the only way to get a primitive int in Clojure 1.3). I think it's better that Clojure be consistent in its treatment of Integer objects and primitive ints by not changing the types on you. -Nathan On Oct 20, 10:19 am, Justin Kramer wrote: > 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) > (getType [this ^long x] :long) > ;; etc > (getType [this ^Object x] :object)) > > (defmacro primitive-type [x] > `(.getType (PrimitiveTester.) ~x)) > > (comment > > user=> (primitive-type (Integer. 5)) > :object > user=> (primitive-type (Integer/parseInt "5")) > :int > > ) > > > > > > > > On Thursday, October 20, 2011 1:13:03 PM UTC-4, Justin Kramer wrote: > > > 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 elided > > ) > > > (defmacro primitive-type [x] > > `(.getType (PrimitiveTester.) ~x)) > > > (comment > > > user=> (primitive-type 5) ;unboxed > > :long > > user=> (primitive-type (Integer/parseInt "5")) ;unboxed > > :int > > user=> (class (Integer/parseInt "5")) ;boxed > > java.lang.Long > > > ) > > > Justin -- 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
Re: Clojure 1.3 treatment of integers and longs
Oops, I meant "Clojure should box primitive ints as Integers." :-) On Oct 20, 12:15 pm, nathanmarz 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 primitive ints as Longs. > > Stu, I wouldn't say Clojure's behavior makes it "just work". For > example, if I obtained by number using Integer/valueOf, then Clojure > will not change the Integer to a Long and will not prevent me from > putting it in a collection. It's confusing that Integer/valueOf will > stay an Integer in Clojure-land, and Integer/parseInt will become a > Long in Clojure-land. > > The use case I'm interested in here is just this one point of Java > interop: what Clojure does with primitive ints that it gets from a > Java object (as far as I can tell, this is the only way to get a > primitive int in Clojure 1.3). I think it's better that Clojure be > consistent in its treatment of Integer objects and primitive ints by > not changing the types on you. > > -Nathan > > On Oct 20, 10:19 am, Justin Kramer wrote: > > > > > > > > > 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) > > (getType [this ^long x] :long) > > ;; etc > > (getType [this ^Object x] :object)) > > > (defmacro primitive-type [x] > > `(.getType (PrimitiveTester.) ~x)) > > > (comment > > > user=> (primitive-type (Integer. 5)) > > :object > > user=> (primitive-type (Integer/parseInt "5")) > > :int > > > ) > > > On Thursday, October 20, 2011 1:13:03 PM UTC-4, Justin Kramer wrote: > > > > 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 elided > > > ) > > > > (defmacro primitive-type [x] > > > `(.getType (PrimitiveTester.) ~x)) > > > > (comment > > > > user=> (primitive-type 5) ;unboxed > > > :long > > > user=> (primitive-type (Integer/parseInt "5")) ;unboxed > > > :int > > > user=> (class (Integer/parseInt "5")) ;boxed > > > java.lang.Long > > > > ) > > > > Justin -- 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
Re: Clojure 1.3 treatment of integers and longs
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 change, the semantics gave you a free lunch around primitive ints in the interop scenario. Now you have be explicit just as you do with pretty much any kind of Java interop. David On Thu, Oct 20, 2011 at 3:16 PM, nathanmarz wrote: > Oops, I meant "Clojure should box primitive ints as Integers." :-) > > > > On Oct 20, 12:15 pm, nathanmarz 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 primitive ints as Longs. > > > > Stu, I wouldn't say Clojure's behavior makes it "just work". For > > example, if I obtained by number using Integer/valueOf, then Clojure > > will not change the Integer to a Long and will not prevent me from > > putting it in a collection. It's confusing that Integer/valueOf will > > stay an Integer in Clojure-land, and Integer/parseInt will become a > > Long in Clojure-land. > > > > The use case I'm interested in here is just this one point of Java > > interop: what Clojure does with primitive ints that it gets from a > > Java object (as far as I can tell, this is the only way to get a > > primitive int in Clojure 1.3). I think it's better that Clojure be > > consistent in its treatment of Integer objects and primitive ints by > > not changing the types on you. > > > > -Nathan > > > > On Oct 20, 10:19 am, Justin Kramer wrote: > > > > > > > > > > > > > > > > > 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) > > > (getType [this ^long x] :long) > > > ;; etc > > > (getType [this ^Object x] :object)) > > > > > (defmacro primitive-type [x] > > > `(.getType (PrimitiveTester.) ~x)) > > > > > (comment > > > > > user=> (primitive-type (Integer. 5)) > > > :object > > > user=> (primitive-type (Integer/parseInt "5")) > > > :int > > > > > ) > > > > > On Thursday, October 20, 2011 1:13:03 PM UTC-4, Justin Kramer wrote: > > > > > > 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 elided > > > > ) > > > > > > (defmacro primitive-type [x] > > > > `(.getType (PrimitiveTester.) ~x)) > > > > > > (comment > > > > > > user=> (primitive-type 5) ;unboxed > > > > :long > > > > user=> (primitive-type (Integer/parseInt "5")) ;unboxed > > > > :int > > > > user=> (class (Integer/parseInt "5")) ;boxed > > > > java.lang.Long > > > > > > ) > > > > > > Justin > > -- > 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
Re: Question:Multi-Core processor affinity for load balancing Clojure Web apps
I don't think so. Jetty is also multi-threaded; each request will be served by a new thread (within a bounded thread pool). Secondly, processor affinity is almost always a bad idea; the OS is pretty good at doing this for you. At the very least I would have a test harness which measures the behaviour of the application under heavy concurrent access - I would be amazed if you any benefit from your approach. I wouldn't be surprised at all if it becomes much worse - sorry :). Note; I am not a performance specialist and even if I claimed to be one you should always take advice with a pinch of salt. It should be fairly easy to measure the difference between the two deployment models yourself. Sorry. On 20 October 2011 19:41, Tim Robinson wrote: > This may not be a Clojure specific kind of question, but this is for > my Clojure web app(s) so hopefully it's not too far off. > > Currently when I deploy my web apps I run 1 app instance on 1 app > server. Given these are multi-core servers I am thinking about running > 4 app instances on a server to get max IO capabilities at a lower > cost. (Note that I currently using nginx, to route requests to a > Clojure/Ring+Jetty web app on a specified port. I am expecting that in > order to run 4 app instances I will need to load balance within nginx > to each port and also set the processor affinity for each app instance > to ensure they are balanced across cores). > > So here are my questions: > > 1. Does this idea make sense? why/whynot? > 2. Do you do currently do this for your web apps and can you provide > any insight/experiences that could be helpful? > 3. Is there a way to specify processor affinity within the > application, such that I wouldn't need to manually set them > afterwards? > 4. Are there better ideas to accomplish the same kind of thing? > > Thanks for any help/ideas. > > Tim > > > > -- > 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
Re: Clojure 1.3 treatment of integers and longs
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 see the benefit of boxing primitive ints as Longs given how Integer objects are treated. Right now, if you obtain an Integer object via interop and want it to be compatible with Clojure's regular numerics, you still have to manually convert that Integer object into a Long. What I'm proposing is that you treat primitive ints obtained via interop the exact same way, which avoids the weird type issues that I ran into. -Nathan On Oct 20, 12:26 pm, David Nolen wrote: > 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 change, the semantics gave you a free lunch around > primitive ints in the interop scenario. Now you have be explicit just as you > do with pretty much any kind of Java interop. > > David > > > > > > > > On Thu, Oct 20, 2011 at 3:16 PM, nathanmarz wrote: > > Oops, I meant "Clojure should box primitive ints as Integers." :-) > > > On Oct 20, 12:15 pm, nathanmarz 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 primitive ints as Longs. > > > > Stu, I wouldn't say Clojure's behavior makes it "just work". For > > > example, if I obtained by number using Integer/valueOf, then Clojure > > > will not change the Integer to a Long and will not prevent me from > > > putting it in a collection. It's confusing that Integer/valueOf will > > > stay an Integer in Clojure-land, and Integer/parseInt will become a > > > Long in Clojure-land. > > > > The use case I'm interested in here is just this one point of Java > > > interop: what Clojure does with primitive ints that it gets from a > > > Java object (as far as I can tell, this is the only way to get a > > > primitive int in Clojure 1.3). I think it's better that Clojure be > > > consistent in its treatment of Integer objects and primitive ints by > > > not changing the types on you. > > > > -Nathan > > > > On Oct 20, 10:19 am, Justin Kramer wrote: > > > > > 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) > > > > (getType [this ^long x] :long) > > > > ;; etc > > > > (getType [this ^Object x] :object)) > > > > > (defmacro primitive-type [x] > > > > `(.getType (PrimitiveTester.) ~x)) > > > > > (comment > > > > > user=> (primitive-type (Integer. 5)) > > > > :object > > > > user=> (primitive-type (Integer/parseInt "5")) > > > > :int > > > > > ) > > > > > On Thursday, October 20, 2011 1:13:03 PM UTC-4, Justin Kramer wrote: > > > > > > 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 elided > > > > > ) > > > > > > (defmacro primitive-type [x] > > > > > `(.getType (PrimitiveTester.) ~x)) > > > > > > (comment > > > > > > user=> (primitive-type 5) ;unboxed > > > > > :long > > > > > user=> (primitive-type (Integer/parseInt "5")) ;unboxed > > > > > :int > > > > > user=> (class (Integer/parseInt "5")) ;boxed > > > > > java.lang.Long > > > > > > ) > > > > > > Justin > > > -- > > 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.
Re: Clojure 1.3 treatment of integers and longs
On Thu, Oct 20, 2011 at 3:45 PM, nathanmarz 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 harder is orthogonal. You do know that Clojure now supports primitive args and return, right? How is what you proposing going to be reconciled with that? 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
Re: Clojure 1.3 treatment of integers and longs
On Thu, Oct 20, 2011 at 12:45 PM, nathanmarz 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 primitive, an int is. > > 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 see the benefit of > boxing primitive ints as Longs given how Integer objects are treated. > Right now, if you obtain an Integer object via interop and want it to > be compatible with Clojure's regular numerics, you still have to > manually convert that Integer object into a Long. What I'm proposing > is that you treat primitive ints obtained via interop the exact same > way, which avoids the weird type issues that I ran into. > > -Nathan > > > On Oct 20, 12:26 pm, David Nolen wrote: >> 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 change, the semantics gave you a free lunch around >> primitive ints in the interop scenario. Now you have be explicit just as you >> do with pretty much any kind of Java interop. >> >> David >> >> >> >> >> >> >> >> On Thu, Oct 20, 2011 at 3:16 PM, nathanmarz wrote: >> > Oops, I meant "Clojure should box primitive ints as Integers." :-) >> >> > On Oct 20, 12:15 pm, nathanmarz 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 primitive ints as Longs. >> >> > > Stu, I wouldn't say Clojure's behavior makes it "just work". For >> > > example, if I obtained by number using Integer/valueOf, then Clojure >> > > will not change the Integer to a Long and will not prevent me from >> > > putting it in a collection. It's confusing that Integer/valueOf will >> > > stay an Integer in Clojure-land, and Integer/parseInt will become a >> > > Long in Clojure-land. >> >> > > The use case I'm interested in here is just this one point of Java >> > > interop: what Clojure does with primitive ints that it gets from a >> > > Java object (as far as I can tell, this is the only way to get a >> > > primitive int in Clojure 1.3). I think it's better that Clojure be >> > > consistent in its treatment of Integer objects and primitive ints by >> > > not changing the types on you. >> >> > > -Nathan >> >> > > On Oct 20, 10:19 am, Justin Kramer wrote: >> >> > > > 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) >> > > > (getType [this ^long x] :long) >> > > > ;; etc >> > > > (getType [this ^Object x] :object)) >> >> > > > (defmacro primitive-type [x] >> > > > `(.getType (PrimitiveTester.) ~x)) >> >> > > > (comment >> >> > > > user=> (primitive-type (Integer. 5)) >> > > > :object >> > > > user=> (primitive-type (Integer/parseInt "5")) >> > > > :int >> >> > > > ) >> >> > > > On Thursday, October 20, 2011 1:13:03 PM UTC-4, Justin Kramer wrote: >> >> > > > > 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 elided >> > > > > ) >> >> > > > > (defmacro primitive-type [x] >> > > > > `(.getType (PrimitiveTester.) ~x)) >> >> > > > > (comment >> >> > > > > user=> (primitive-type 5) ;unboxed >> > > > > :long >> > > > > user=> (primitive-type (Integer/parseInt "5")) ;unboxed >> > > > > :int >> > > > > user=> (class (Integer/parseInt "5")) ;boxed >> > > > > java.lang.Long >> >> > > > > ) >> >> > > > > Justin >> >> > -- >> > 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 >
Re: Clojure 1.3 treatment of integers and longs
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. Right now, it boxes ints as a Long, which I think is changing the type. My proposal is that it box ints as Integer objects. Would changing the behavior in this way cause a fundamental performance limitation in Clojure? -Nathan On Oct 20, 12:50 pm, David Nolen wrote: > On Thu, Oct 20, 2011 at 3:45 PM, nathanmarz 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 harder > is orthogonal. > > You do know that Clojure now supports primitive args and return, right? How > is what you proposing going to be reconciled with that? > > 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
Re: Clojure 1.3 "wonky" behavior
To put it another way: a top-level "do" is special-cased to compile and then immediately execute each contained form, in order. Any other top-level form, such as "list", will be fully compiled, including all contained forms, and only then executed. In this case, the defn cannot compile because the preceding declare has not yet executed - it has only compiled. - Chris -- 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
Re: Clojure 1.3 "wonky" behavior
Note: I forgot to preface that with "I think..." :) Upon experimenting briefly, it turns out I was wrong about how Clojure works (that seems to happen a lot with me). A declare/def defines a var even when it's not executed! user> (defn xxx [] (declare yyy)) #'user/xxx user> yyy # Well, I learned something today. - Chris -- 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
Re: Is there a reader setting support BigDecimal by default?
Thank for the replies and I appreciate the suggestions, however they some of the rationale behind them doesn't match well my experience. First, BigDecimal is plenty fast the large business systems I've worked on. Actually, it has been plenty fast for every large business system I've worked on. This includes a group insurance rate engine that generated hundreds of thousands of calculations in each web request. Second, storing values with implied decimal points is a nightmare. In the insurance application for example, some of the rate tables have precision to three decimal places, others to five. Picking some arbitrary value imposes code complexity throughout the whole in app in a very nasty way. Of course, what happens when you need to change that value two years from now? Unless there's a really good performance issue for a given application, I would never pick implied decimal representation over BigDecimals. Finally, for the business applications I've worked with, I haven't had to worry about representing all rationals, just base 10 numbers. In my experience, using BigDecimal by default for any number with a decimal point has worked out very well for balancing the needs of accuracy, speed and code complexity. It appears that the answer to the original question is "no, there is no way to configure the reader to default numbers with a decimal point to be BigDecimal instead of Double". Scott Hickey -- 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
Re: Is there a reader setting support BigDecimal by default?
Scott: "no, there is no way to configure the reader to default numbers with a decimal point to be BigDecimal instead of Double" Correct. But you can modify the Reader: it's just Java code. -S -- 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
Re: Is there a reader setting support BigDecimal by default?
> It appears that the answer to the original question is "no, there is no way > to configure the reader to default numbers with a decimal point to be > BigDecimal instead of Double". > > Scott Hickey Reading a double implies that somebody upstream of you was using doubles, which violates the guarantees you want from BigDecimals. Why is the upstream provider using doubles? Stu -- 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
Re: Is there a reader setting support BigDecimal by default?
On Thu, Oct 20, 2011 at 22:50, Stuart Halloway wrote: >> It appears that the answer to the original question is "no, there is no way >> to configure the reader to default numbers with a decimal point to be >> BigDecimal instead of Double". >> >> Scott Hickey > > Reading a double implies that somebody upstream of you was using doubles, > which violates the guarantees you want from BigDecimals. > > Why is the upstream provider using doubles? I don't follow. The OP has text, which Clojure is reading as doubles. This only implies that upstream (which need not have been written in Clojure) is producing numbers matching #"[-]?[1-9][0-9]*[.][0-9]*|0", because LispReader interprets that as Double. Whatever internal representation this text was produced form may or may not have been (binary) floating point initially. It doesn't seem reasonable to assume that the OP's "'business' applications I've built over the last 25 years" could have known that Clojure would come along later and expect to find "M" on the end of every decimal number. // Ben // Ben -- 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
Re: Is there a reader setting support BigDecimal by default?
>>> It appears that the answer to the original question is "no, there is no way >>> to configure the reader to default numbers with a decimal point to be >>> BigDecimal instead of Double". >>> >>> Scott Hickey >> >> Reading a double implies that somebody upstream of you was using doubles, >> which violates the guarantees you want from BigDecimals. >> >> Why is the upstream provider using doubles? > > I don't follow. The OP has text, which Clojure is reading as doubles. > This only implies that upstream (which need not have been written in > Clojure) is producing numbers matching #"[-]?[1-9][0-9]*[.][0-9]*|0", > because LispReader interprets that as Double. Whatever internal > representation this text was produced form may or may not have been > (binary) floating point initially. > > It doesn't seem reasonable to assume that the OP's "'business' > applications I've built over the last 25 years" could have known that > Clojure would come along later and expect to find "M" on the end of > every decimal number. > > // Ben Hmm, highly apropos discussion since Rich's talk on simplicity posted today. The reader does one thing: read Clojure data. Sometimes you need something else: read data written in another format. You might accomplish that by (1) making the reader able to do two things, adding a flag to deal with a specific format, or (2) by using a different reader for that job. (2) is hands-down the right answer. Stu -- 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
Re: Is there a reader setting support BigDecimal by default?
On Thu, Oct 20, 2011 at 23:16, Stuart Halloway wrote: It appears that the answer to the original question is "no, there is no way to configure the reader to default numbers with a decimal point to be BigDecimal instead of Double". Scott Hickey >>> >>> Reading a double implies that somebody upstream of you was using doubles, >>> which violates the guarantees you want from BigDecimals. >>> >>> Why is the upstream provider using doubles? >> >> I don't follow. The OP has text, which Clojure is reading as doubles. >> This only implies that upstream (which need not have been written in >> Clojure) is producing numbers matching #"[-]?[1-9][0-9]*[.][0-9]*|0", >> because LispReader interprets that as Double. Whatever internal >> representation this text was produced form may or may not have been >> (binary) floating point initially. >> >> It doesn't seem reasonable to assume that the OP's "'business' >> applications I've built over the last 25 years" could have known that >> Clojure would come along later and expect to find "M" on the end of >> every decimal number. >> >> // Ben > > Hmm, highly apropos discussion since Rich's talk on simplicity posted today. > > The reader does one thing: read Clojure data. Sometimes you need something > else: read data written in another format. You might accomplish that by (1) > making the reader able to do two things, adding a flag to deal with a > specific format, or (2) by using a different reader for that job. > > (2) is hands-down the right answer. No argument there. The Clojure reader's job is to read Clojure. If your have some data that happens to be syntactically compatible, fine, but if not the Clojure reader isn't the right tool. One obvious approach would be a to use a regular expression to identify the numbers in the text to be parsed and #(BigDecimal. ^String %) to do the actual conversion. // Ben -- 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
Re: Question:Multi-Core processor affinity for load balancing Clojure Web apps
I would suspect that you would not get a _significant_ performance advantage from specifying processor affinity, but if you really want to measure it and find out by experimentation, read on. I was not able to find any portable way within a JVM to set processor affinity, after some amount of Googling on the Internet about a year ago. There might be some ways that are specific to some JVMs, but I didn't find any then. If you want to set the processor affinity for an arbitrary process running on Linux, whether it is a JVM or not, you can do so with a sched_affinity() call in a little wrapper process that starts up the process for you. According to the StackOverflow discussion linked below, user tgamblin found that sched_affinity() semantics can vary across Linux distributions. They mention a Portable Linux Processor Affinity library that may be useful, although I haven't tried it myself. They mention that for some high-performance parallel applications, e.g. using the MPI library, it is common practice to manually specify processor affinity. http://stackoverflow.com/questions/360307/multicore-hyperthreading-how-are-threads-distributed Note that if you benchmark manually setting processor affinity vs. not, note that benchmarking this with programs that use very little memory (e.g. an infinite loop that just counts iterations) will likely not show as much difference as a benchmark that has significant usage of the on-chip CPU instruction and/or data cache, so that switching the scheduling of the thread to a different CPU core actually causes significant cache misses after being "moved". Andy On Thu, Oct 20, 2011 at 11:41 AM, Tim Robinson wrote: > This may not be a Clojure specific kind of question, but this is for > my Clojure web app(s) so hopefully it's not too far off. > > Currently when I deploy my web apps I run 1 app instance on 1 app > server. Given these are multi-core servers I am thinking about running > 4 app instances on a server to get max IO capabilities at a lower > cost. (Note that I currently using nginx, to route requests to a > Clojure/Ring+Jetty web app on a specified port. I am expecting that in > order to run 4 app instances I will need to load balance within nginx > to each port and also set the processor affinity for each app instance > to ensure they are balanced across cores). > > So here are my questions: > > 1. Does this idea make sense? why/whynot? > 2. Do you do currently do this for your web apps and can you provide > any insight/experiences that could be helpful? > 3. Is there a way to specify processor affinity within the > application, such that I wouldn't need to manually set them > afterwards? > 4. Are there better ideas to accomplish the same kind of thing? > > Thanks for any help/ideas. > > Tim > > > > -- > 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
Re: Clojure 1.3 "wonky" behavior
On Thu, Oct 20, 2011 at 4:31 PM, Chris Perkins wrote:
> Note: I forgot to preface that with "I think..." :) Upon experimenting
> briefly, it turns out I was wrong about how Clojure works (that seems to
> happen a lot with me). A declare/def defines a var even when it's not
> executed!
> user> (defn xxx [] (declare yyy))
> #'user/xxx
> user> yyy
> #
> Well, I learned something today.
But it only interns the Var, it doesn't fully set it up. Particularly
relevant to the OP's example is that the metadata from the name symbol
is not transferred to the Var (and the changes to the Var based on
:dynamic are not applied) until runtime for the 'def', even though the
Var exists at compile time.
Here's a macro that expands at compile time to the *compile* time
metadata of the var named in its argument:
(defmacro compile-time-meta [x] (meta (resolve x)))
Now observe how it behaves differently than a runtime call to 'meta':
(vector
(declare ^:dynamic *myvar*)
(meta #'*myvar*)
(compile-time-meta #'*myvar*)))
The above returns:
[#'user/*myvar*
{:ns #, :name *myvar*, :dynamic true, :declared true, ...}
{:ns #, :name #}]
First is the Var itself.
Next is the metadata of the Var at runtime, after the entire form has
been compiled and therefore the metadata from the name has been
applied to the Var, including the :dynamic flag.
Finally we see that when our macro was expanded the Var existed but
had minimal metadata. This was after the declare was compiled but
before any part of the 'vector' form was run. There is no :dynamic
flag, and anything that depends on that flag at compile time to work
correctly (such as a function that refers the for Var) will fail to
work correctly.
--Chouser
--
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
Finding a function's expected argument list length
For some work I'm doing it would be very nice to be able to know the number of arguments any given function expects to be called with. Is there anyway to get this information at run-time in Clojure? Thanks. -- 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
Re: Clojure 1.3 treatment of integers and longs
On Thu, Oct 20, 2011 at 1:11 PM, nathanmarz 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 interop call that expects an int) - based on what I've understood of the numerics discussions. Similarly, you only have a primitive float if you coerce the value. So Clojure boxes a long as Long. If you want to box a long as Integer, you have to explicitly say so: (Integer. 42) - and Clojure will give you an Integer and not do anything to it. (Is my understanding correct? I'm finding the discussion interesting but not 100% sure whether I fully understand Clojure 1.3's primitive numerics) -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ Railo Technologies, Inc. -- http://www.getrailo.com/ "Perfection is the enemy of the good." -- Gustave Flaubert, French realist novelist (1821-1880) -- 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
Re: Clojure 1.3 treatment of integers and longs
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 as a significant cost in a computation. One of the purpose of normalizing to 64 bits was to get maximum performance for compute bound Clojure applications. Computing with wrappers is inefficient. Your proposal looks only at one facet of the whole problem. It's not a Java centric issue, it's a Clojure performance enhancement. You are coding in Clojure, not in Java. It happens that Clojure reuses some native types efficiently implemented by the JVM and used by Java (String, long, ) but not all of them. Let's say one day you end up coding in ClojureScript or Clojure on JS, what do you prefer ? Deal with idiosyncrasies of the underlying environment or have a consistent implementation that provides the best performance for that given pseudo-metal ? What about the day that long long (128 bits) comes around ? Clojure will drag behind because it's carrying 32 bit values ? Obviously it creates issues when you work at the fringe but interop is not the purpose of Clojure. It happens to be much more easier to access the "outside" world than in other environments but it cannot justify to compromise the performance or feature list of Clojure. Luc P. On Thu, 20 Oct 2011 13:11:40 -0700 (PDT) nathanmarz 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. > > Right now, it boxes ints as a Long, which I think is changing the > type. My proposal is that it box ints as Integer objects. Would > changing the behavior in this way cause a fundamental performance > limitation in Clojure? > > -Nathan > > > > > On Oct 20, 12:50 pm, David Nolen wrote: > > On Thu, Oct 20, 2011 at 3:45 PM, nathanmarz > > 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 harder is orthogonal. > > > > You do know that Clojure now supports primitive args and return, > > right? How is what you proposing going to be reconciled with that? > > > > David > -- 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
Re: Clojure 1.3 treatment of integers and longs
On Thu, Oct 20, 2011 at 4:11 PM, nathanmarz 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
Re: Will clojurescript get in-ns and load?
There is a load-file function in clojurescript, I'm guessing that doesn't do what you want? Scott On Thu, Oct 20, 2011 at 1:07 PM, Dave Sann wrote: > Thinking further, the capability would not be of use (to me) if it were not > consistent/indistinguishable across clojure and clojurescript. > > I have seen in-ns and load used to effectively split a namespace across > files > > If 'in-ns' and 'load' were implemented for clojurescript, could 'load' be > managed as a compile time operation to merge the namespaces. > > Perhaps there are better ways of achieving this that I am not aware of. > > Cheers > > D > > -- > 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
partial, but instead of args + additional, get additional + args
Hi guys, I fall out in many situations that I want the partial, but inversed, a simple example: Let's say I wanna all primes bellow 2.000: (take-while (partial > 2000) primes) In this case, that's ok, but I don't expressed myself write, I because I had to use the oposite of < to create the partial, I wanna do something: (take-while (rpartial < 2000) primes) In the case of <> it's ok because they are reverse of each other, but in some circustances there is no reverse function, and you finish can't be using partial, instead you do like: (take-while #(< % 2000) primes) I mean, there is no such function on default that works as reversed arguments partial (appending partial arguments at end instead of beginning)? If it don't, is not a good idea to have one? --- Wilker Lúcio http://about.me/wilkerlucio/bio Kajabi Consultant +55 81 82556600 -- 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
Re: Rich Hickey: "Simple Made Easy" from Strange Loop 2011
I can understand your situation because I've seen a C# code where most of the classes in some 5-6 different assemblies had all (or 90%) static methods :) -- 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
Re: Clojure jar files.
Clojure.jar does not have a project.clj file because it is all java code, right? If it is all java code then it's a (java) jar file. I found this convention of bundling a clojure jar file with a project.clj file - lein does this and that's all I know - so I was curious to know if every other build tool which people use does the same thing? -- 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
Re: Finding a function's expected argument list length
No. The summary is: from Java's point of view every function is "willing" to accept any number of args, but many of the implementations throw an exception. Vars have an :arglists metadata key, but that is not generally present on functions. I agree it would be nice if function objects carried a set of "acceptable arities" with them, but I haven't thought very hard about it - perhaps the performance implication this imposes on every function isn't worth it for the small minority of times when you need to ask the question. On Oct 20, 5:58 pm, Alex Baranosky wrote: > For some work I'm doing it would be very nice to be able to know the number > of arguments any given function expects to be called with. Is there anyway > to get this information at run-time in Clojure? > > Thanks. -- 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
Re: Finding a function's expected argument list length
In a REPL,
user> (defn hello [name]
(println "hi," name))
#'user/hello
user> (meta (var hello))
{:ns #, :name hello, :file "NO_SOURCE_FILE", :line 1,
:arglists ([name])}
Please also check - http://clojuredocs.org/clojure_core/clojure.core/meta
--
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
Re: Clojure jar files.
Manoj, On Fri, Oct 21, 2011 at 9:09 AM, mmwaikar wrote: > Clojure.jar does not have a project.clj file because it is all java code, > right? If it is all java code then it's a (java) jar file. > > I found this convention of bundling a clojure jar file with a project.clj > file - lein does this and that's all I know - so I was curious to know if > every > other build tool which people use does the same thing? Clojure has a lot of Clojure code as well! The only difference is that it doesn't use Leiningen for building the project, but instead uses Maven directly. If you are going to upload your library to any Maven (or similar) repo that's accessible through Leiningen, then you may choose to not include a project.clj file; in any case, if you yourself are using Leiningen, you should include that file. FWIW, Leiningen can generate pom.xml files from project.clj as well. Regards, BG -- Baishampayan Ghose b.ghose at gmail.com -- 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
Re: Finding a function's expected argument list length
I figured, but had to ask. I'm looking into adding a feature to Midje to be able to say: (defn g [a b c d e f g] nil) (fact (f 1) => 1 (provided (g ...) :never )) instead of what you currently have to say for the equivalent: (fact (f 1) => 1 (provided (g anything anything anything anything anything anything anything) => anything :never )) Knowing the arity of the function would have helped with the internals. On Thu, Oct 20, 2011 at 11:42 PM, Alan Malloy wrote: > No. The summary is: from Java's point of view every function is > "willing" to accept any number of args, but many of the > implementations throw an exception. Vars have an :arglists metadata > key, but that is not generally present on functions. I agree it would > be nice if function objects carried a set of "acceptable arities" with > them, but I haven't thought very hard about it - perhaps the > performance implication this imposes on every function isn't worth it > for the small minority of times when you need to ask the question. > > On Oct 20, 5:58 pm, Alex Baranosky > wrote: > > For some work I'm doing it would be very nice to be able to know the > number > > of arguments any given function expects to be called with. Is there > anyway > > to get this information at run-time in Clojure? > > > > Thanks. > > -- > 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
Re: partial, but instead of args + additional, get additional + args
On Thu, Oct 20, 2011 at 8:15 PM, Wilker wrote: > In the case of <> it's ok because they are reverse of each other, but in > some circustances there is no reverse function, and you finish can't be > using partial, instead you do like: > > (take-while #(< % 2000) primes) > > I mean, there is no such function on default that works as reversed > arguments partial (appending partial arguments at end instead of beginning)? I was expressing a need for exactly this function the other day on IRC. I jokingly called it 'impartial' :) -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ Railo Technologies, Inc. -- http://www.getrailo.com/ "Perfection is the enemy of the good." -- Gustave Flaubert, French realist novelist (1821-1880) -- 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
Re: Finding a function's expected argument list length
Thanks. I'm going to have to see if that could help with what I'm trying to
do.
On Thu, Oct 20, 2011 at 11:45 PM, mmwaikar wrote:
> In a REPL,
>
> user> (defn hello [name]
> (println "hi," name))
> #'user/hello
>
> user> (meta (var hello))
> {:ns #, :name hello, :file "NO_SOURCE_FILE", :line 1,
> :arglists ([name])}
>
> Please also check - http://clojuredocs.org/clojure_core/clojure.core/meta
>
> --
> 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
Re: partial, but instead of args + additional, get additional + args
Hi, Am 21.10.2011 um 06:01 schrieb Sean Corfield: > On Thu, Oct 20, 2011 at 8:15 PM, Wilker wrote: >> >> (take-while #(< % 2000) primes) > > I was expressing a need for exactly this function the other day on > IRC. I jokingly called it 'impartial' :) What is bad about #(< % 2000)? In fact I would probably write the other case as #(< 2000 %) instead of using partial. The only advantages of partial are a) that it acts like #(apply < 2000 %&) (to stay in the example) and b) that it generates one class less compared to #(). Sincerely Meikel -- 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
Re: Clojure 1.3 treatment of integers and longs
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 wrote:
> On Thu, Oct 20, 2011 at 4:11 PM, nathanmarz 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
Re: partial, but instead of args + additional, get additional + args
Hi Miekel, The main reason is because I feel it is more expressive, and I really love expressive code :) --- Wilker Lúcio http://about.me/wilkerlucio/bio Kajabi Consultant +55 81 82556600 On Thu, Oct 20, 2011 at 9:10 PM, Meikel Brandmeyer wrote: > Hi, > > Am 21.10.2011 um 06:01 schrieb Sean Corfield: > > > On Thu, Oct 20, 2011 at 8:15 PM, Wilker wrote: > >> > >> (take-while #(< % 2000) primes) > > > > I was expressing a need for exactly this function the other day on > > IRC. I jokingly called it 'impartial' :) > > What is bad about #(< % 2000)? In fact I would probably write the other > case as #(< 2000 %) instead of using partial. The only advantages of partial > are a) that it acts like #(apply < 2000 %&) (to stay in the example) and b) > that it generates one class less compared to #(). > > Sincerely > Meikel > > -- > 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
Re: Clojure 1.3 treatment of integers and longs
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 would happen. On Oct 20, 9:11 pm, nathanmarz 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? -- 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
Re: Clojure 1.3 treatment of integers and longs
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 proposing is that when Clojure needs to box a primitive int,
that Clojure box it as an Integer rather than a Long. Then this code
example:
(let [m {:a (Integer/parseInt "1")}]
(map class (vals m)))
will behave the same as this one:
(let [m {:a (Integer/valueOf "1")}]
(map class (vals m)))
-Nathan
On Oct 20, 9:35 pm, Alan Malloy wrote:
> 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 would happen.
>
> On Oct 20, 9:11 pm, nathanmarz 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?
--
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
Re: About metadat and #^ macro.
Thanks everyone for your inputs and the discussion. Manoj. -- 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
Re: Clojure 1.3 treatment of integers and longs
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 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 wrote:
> > On Thu, Oct 20, 2011 at 4:11 PM, nathanmarz
> > 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 a
