Re: updating some values in map
Another way to do it (defn apply-map-fn [m f ks] (reduce #(update-in %1 [%2] f) m ks)) -- 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 Clojure Simple?
2011/10/22 Tim Robinson tim.blacks...@gmail.com: So I've read the previous post Rich Hickey: Simple Made Easy from Strange Loop 2011, but I wanted to ask some simple questions not complected by the interweaving path the other has post followed (is 'complected' even a word? - lol) . I know the presentation was, while inclusive of Clojure, not specific to Clojure and after having given some further thought I find myself wondering where does Clojure sit in this continuum of simple to complectness (ok, yes I am now making up words). And I wonder where do the language designers think Clojure sits? How far along has Clojure gone down this rabbit hole? Is Rich planning to make a new language, because Clojure is 'here', but not 'there' ? - and where is 'here' for Clojure anyway? If your were to rank, in accordance to Rich's inventory of complect items, is Clojure a 5/10? or a 9/10? Do the Clojure language designers plan to make changes to Clojure to make it simpler? And if so, how so? I don't want this to be a battle on Clojure doing 'this' but not 'that' (and I hope that's possible). Since simple definition includes it being an objective property, then if 'battles' start on this thread, this should be the smell that the discussion changes to be about easiness rather than simpleness :-) 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
On Sat, Oct 22, 2011 at 7:53 PM, Luc Prefontaine lprefonta...@softaddicts.ca wrote: Ha ! Ok, I missed the digression here and I now understand the issue. Considering that a PersistentArrayMap may eventually become a PersistentHashMap this opens the door to *funny* bugs. Is this the only known case ? The bug in PersistentHashMap also infects PersistentHashSet. I've created a Jira bug about it you can see the details there: http://dev.clojure.org/jira/browse/CLJ-861 Paul -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure 1.3 treatment of integers and longs
On Sat, Oct 22, 2011 at 5:51 PM, Stuart Halloway stuart.hallo...@gmail.comwrote: I am dropping off this thread now. At this point I think it would be more useful for me (or someone) to expand the notes about numerics into better documentation, rather than continuing this rambling point-by-point treatment without getting all of the considerations into play at once. I hope to get that done by conj. So you are still thinking that the current behavior is OK and just needs to be documented better? Or are you saying that we need to collect the various pros and cons to decide whether the current behavior should change or remain the same? Having reviewed the thread there is lots of confusion, but from the points made it seems clear to me that the behavior should change. CON (The we should box ints as Longs (or we should keep things as they are) camp): 1) If we box ints as Integers it will break Clojure's collections (Stu Halloway) 2) Boxing ints as Integers would make Clojure's design inconsistent (David Nolen) 3) Clojure now only has 64-bit primitives (David Nolen/Kevin Downey) 4) If 32-bit ints are allowed to exist, the Clojure's numeric operators would have to handle them (David Nolen) CON1 is a bug in PersistentHashMap, and I opened a Jira bug for it ( http://dev.clojure.org/jira/browse/CLJ-861). CON2 is false. The way primitives are boxed for interop doesn't and shouldn't have any effect on Clojure's design as such. This is a discussion about interop consistency, and if you look at the PRO section you will see Clojure is already inconsistent with respect to interop. Nathan and others are arguing that it should be made consistent. CON3 is false. 32-bit primitives do exist in Clojure (at least Java Clojure), they are just not the optimized case. They may get immediately converted to longs or boxed in some way, but we cannot deny their existence, especially around interop. CON4 Again, 32-bit integers do exist, and are already handled by the numeric operators. When you compile a function with primitive args, Clojure also generates a method that takes Objects. If you pass in anything other than a long it gets boxed, cast to a java.lang.Number, has its longValue method called, and that value gets passed to the primitive arg version. This is slow (as expected) because you are not using the optimized case (64-bit primitives). Absolutely none of that would have to change/get slower because ints were boxed as Integers instead of Longs. I think the problem with all of these CONs is that they confuse boxing for interop with either a bug in PersistentHashMap, or fast primitive maths, and neither of those has anything to do with how ints are boxed. PRO (The we should box ints as Integers camp): 1) Clojure is inconsistent in how it boxes primitive data (Chris Perkins) Clojure 1.3: (class (Long/parseLong 1)) = java.lang.Long (class (Integer/parseInt 1)) = java.lang.Long (class (Short/parseShort 1)) = java.lang.Short (class (Byte/parseByte 1)) = java.lang.Byte (class (Float/parseFloat 1)) = java.lang.Float (class (Double/parseDouble 1)) = java.lang.Double Paul -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
ClojureScript: Map to ExtJS/Sencha Touch Config Object
I wrote some functions to convert a map into an ExtJS/Sencha Touch config object. It converts nested list and vectors into javascript arrays. https://gist.github.com/1307273 Matt Hoyt -- 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: updating some values in map
Hey thanks Stephen and BG, and Jonas! Cool tricks I hadn't thought of. I'm especially going to study this one; I had thought update-in might be applicable but I wasn't sure how (still learning it). I appreciate it! Mike On Oct 23, 2:10 am, Jonas jonas.enl...@gmail.com wrote: Another way to do it (defn apply-map-fn [m f ks] (reduce #(update-in %1 [%2] f) m ks)) -- 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
CON1 - I'm buying your argumentation about consistency in Clojure maps and fixing them. Integer OBJECTS (as opposed to int primitive) should be handle as objects consistenly, not as primitive values promoted to long. CON2, CON3 and CON4 - No way, the current design choice is the good one. So many languages have been plagued with numbers of different sizes/formats for ints and floating point values, it's not a direction that Clojure should follow. These distinct types are source of many problems (overflow handling, precision problems, ...). The need for Clojure to support these things is similar to calling assembler from C. You matter about bytes, shorts and similar things at the frontier, when it's time to call a low level service, you need to be able to pass these values. By no means this implies that you have to support them in your language runtime. It complects (;) everything including computations and makes your runtime much more harder to port. It's an interop centric thing and interop is by essence not portable. It does not belong to the core of Clojure. It's better to rely on cast operators to call interop than to expect Clojure to box numeric values according to some interop convention that may vary according to the platform Clojure runs on. Luc P. On Sun, 23 Oct 2011 07:19:41 -0400 Paul Stadig p...@stadig.name wrote: On Sat, Oct 22, 2011 at 5:51 PM, Stuart Halloway stuart.hallo...@gmail.comwrote: I am dropping off this thread now. At this point I think it would be more useful for me (or someone) to expand the notes about numerics into better documentation, rather than continuing this rambling point-by-point treatment without getting all of the considerations into play at once. I hope to get that done by conj. So you are still thinking that the current behavior is OK and just needs to be documented better? Or are you saying that we need to collect the various pros and cons to decide whether the current behavior should change or remain the same? Having reviewed the thread there is lots of confusion, but from the points made it seems clear to me that the behavior should change. CON (The we should box ints as Longs (or we should keep things as they are) camp): 1) If we box ints as Integers it will break Clojure's collections (Stu Halloway) 2) Boxing ints as Integers would make Clojure's design inconsistent (David Nolen) 3) Clojure now only has 64-bit primitives (David Nolen/Kevin Downey) 4) If 32-bit ints are allowed to exist, the Clojure's numeric operators would have to handle them (David Nolen) CON1 is a bug in PersistentHashMap, and I opened a Jira bug for it ( http://dev.clojure.org/jira/browse/CLJ-861). CON2 is false. The way primitives are boxed for interop doesn't and shouldn't have any effect on Clojure's design as such. This is a discussion about interop consistency, and if you look at the PRO section you will see Clojure is already inconsistent with respect to interop. Nathan and others are arguing that it should be made consistent. CON3 is false. 32-bit primitives do exist in Clojure (at least Java Clojure), they are just not the optimized case. They may get immediately converted to longs or boxed in some way, but we cannot deny their existence, especially around interop. CON4 Again, 32-bit integers do exist, and are already handled by the numeric operators. When you compile a function with primitive args, Clojure also generates a method that takes Objects. If you pass in anything other than a long it gets boxed, cast to a java.lang.Number, has its longValue method called, and that value gets passed to the primitive arg version. This is slow (as expected) because you are not using the optimized case (64-bit primitives). Absolutely none of that would have to change/get slower because ints were boxed as Integers instead of Longs. I think the problem with all of these CONs is that they confuse boxing for interop with either a bug in PersistentHashMap, or fast primitive maths, and neither of those has anything to do with how ints are boxed. PRO (The we should box ints as Integers camp): 1) Clojure is inconsistent in how it boxes primitive data (Chris Perkins) Clojure 1.3: (class (Long/parseLong 1)) = java.lang.Long (class (Integer/parseInt 1)) = java.lang.Long (class (Short/parseShort 1)) = java.lang.Short (class (Byte/parseByte 1)) = java.lang.Byte (class (Float/parseFloat 1)) = java.lang.Float (class (Double/parseDouble 1)) = java.lang.Double Paul -- Luc P. The rabid Muppet -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at
Re: clojure starter package for aichallenge ?
Hi Chris, Thanks for your startup-package. Can you please tell me if there is a test_bot.sh for clojure. Can share if you already have one? Thanks, Sunil. On Sat, Oct 22, 2011 at 12:16 PM, Chris Granger ibdk...@gmail.com wrote: Hm? My starter package is there: http://aichallenge.org/starter_packages.php They changed the game at the end and I didn't have time to update it for hills, but it actually works just fine as is. Also, it should be fairly trivial for someone to add that bit... Cheers, Chris. On Oct 20, 11:58 am, faenvie fanny.aen...@gmx.de wrote: hi clojure community, at the moment there seems to be no applicable clojure starter package for thehttp://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 -- 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 starter package for aichallenge ?
Hi Chris, I am sorry, I think I needed to be a little more specific. I get a bad submission key found error when I submit.. Sunil. On Sun, Oct 23, 2011 at 9:16 PM, Sunil S Nandihalli sunil.nandiha...@gmail.com wrote: Hi Chris, Thanks for your startup-package. Can you please tell me if there is a test_bot.sh for clojure. Can share if you already have one? Thanks, Sunil. On Sat, Oct 22, 2011 at 12:16 PM, Chris Granger ibdk...@gmail.com wrote: Hm? My starter package is there: http://aichallenge.org/starter_packages.php They changed the game at the end and I didn't have time to update it for hills, but it actually works just fine as is. Also, it should be fairly trivial for someone to add that bit... Cheers, Chris. On Oct 20, 11:58 am, faenvie fanny.aen...@gmx.de wrote: hi clojure community, at the moment there seems to be no applicable clojure starter package for thehttp://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 -- 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
Hello Luc, In all fairness I don't see how converting ints to Integers returned by class methods would break the abstraction. If you start talking about portability of Clojure code, then Long is as portable as Integer is. (In general they are not.) Could you explain your position on the fact that shorts get converted to Short? Why is it not possible to do the same for ints? I don't think that there was anyone in this thread that would suggest keeping 32bit math in Clojure. For what it's worth, Integer can be converted to Long first time it is used in any computation. Cheers, Ivan. On 23 October 2011 17:16, Luc Prefontaine lprefonta...@softaddicts.cawrote: CON1 - I'm buying your argumentation about consistency in Clojure maps and fixing them. Integer OBJECTS (as opposed to int primitive) should be handle as objects consistenly, not as primitive values promoted to long. CON2, CON3 and CON4 - No way, the current design choice is the good one. So many languages have been plagued with numbers of different sizes/formats for ints and floating point values, it's not a direction that Clojure should follow. These distinct types are source of many problems (overflow handling, precision problems, ...). The need for Clojure to support these things is similar to calling assembler from C. You matter about bytes, shorts and similar things at the frontier, when it's time to call a low level service, you need to be able to pass these values. By no means this implies that you have to support them in your language runtime. It complects (;) everything including computations and makes your runtime much more harder to port. It's an interop centric thing and interop is by essence not portable. It does not belong to the core of Clojure. It's better to rely on cast operators to call interop than to expect Clojure to box numeric values according to some interop convention that may vary according to the platform Clojure runs on. Luc P. On Sun, 23 Oct 2011 07:19:41 -0400 Paul Stadig p...@stadig.name wrote: On Sat, Oct 22, 2011 at 5:51 PM, Stuart Halloway stuart.hallo...@gmail.comwrote: I am dropping off this thread now. At this point I think it would be more useful for me (or someone) to expand the notes about numerics into better documentation, rather than continuing this rambling point-by-point treatment without getting all of the considerations into play at once. I hope to get that done by conj. So you are still thinking that the current behavior is OK and just needs to be documented better? Or are you saying that we need to collect the various pros and cons to decide whether the current behavior should change or remain the same? Having reviewed the thread there is lots of confusion, but from the points made it seems clear to me that the behavior should change. CON (The we should box ints as Longs (or we should keep things as they are) camp): 1) If we box ints as Integers it will break Clojure's collections (Stu Halloway) 2) Boxing ints as Integers would make Clojure's design inconsistent (David Nolen) 3) Clojure now only has 64-bit primitives (David Nolen/Kevin Downey) 4) If 32-bit ints are allowed to exist, the Clojure's numeric operators would have to handle them (David Nolen) CON1 is a bug in PersistentHashMap, and I opened a Jira bug for it ( http://dev.clojure.org/jira/browse/CLJ-861). CON2 is false. The way primitives are boxed for interop doesn't and shouldn't have any effect on Clojure's design as such. This is a discussion about interop consistency, and if you look at the PRO section you will see Clojure is already inconsistent with respect to interop. Nathan and others are arguing that it should be made consistent. CON3 is false. 32-bit primitives do exist in Clojure (at least Java Clojure), they are just not the optimized case. They may get immediately converted to longs or boxed in some way, but we cannot deny their existence, especially around interop. CON4 Again, 32-bit integers do exist, and are already handled by the numeric operators. When you compile a function with primitive args, Clojure also generates a method that takes Objects. If you pass in anything other than a long it gets boxed, cast to a java.lang.Number, has its longValue method called, and that value gets passed to the primitive arg version. This is slow (as expected) because you are not using the optimized case (64-bit primitives). Absolutely none of that would have to change/get slower because ints were boxed as Integers instead of Longs. I think the problem with all of these CONs is that they confuse boxing for interop with either a bug in PersistentHashMap, or fast primitive maths, and neither of those has anything to do with how ints are boxed. PRO (The we should box ints as Integers camp): 1) Clojure is inconsistent in how it boxes primitive data (Chris Perkins) Clojure 1.3:
Re: partial, but instead of args + additional, get additional + args
Hi, Am 22.10.2011 um 20:49 schrieb Sean Corfield: I'm starting to think there's a nice, idiomatic solution lurking somewhere that wouldn't require an extra function... The idiomatic solution is #(f % a1 a2 a3). I'm failing to see the issue with “nice” and “expressive”, but that is most likely just me. 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
On Sun, 23 Oct 2011 20:31:51 +0200 Ivan Koblik ivankob...@gmail.com wrote: Hello Luc, In all fairness I don't see how converting ints to Integers returned by class methods would break the abstraction. If you start talking about portability of Clojure code, then Long is as portable as Integer is. (In general they are not.) It's simpler to use one representation to port the core. You can choose the fastest/efficient one. You do not have to carry all these intermediate types with you. The day a 128 bits primitive type become available, there's little changes to do to support that. If you keep mixed types, that adds another one to the babel tower. The problem is not to choose between ints or longs, it has to do with carrying all these intermediate types. Frankly aside from interop, how many are using short ints in Clojure ? That's a leftover from the PDP-11 era. Could you explain your position on the fact that shorts get converted to Short? Why is it not possible to do the same for ints? This should disappear. I think all the small primitive types including ints should be promoted to long except when doing an interop call. Rich can explain why it's been kept. Maybe a question of priority/effort or something else. I don't think that there was anyone in this thread that would suggest keeping 32bit math in Clojure. For what it's worth, Integer can be converted to Long first time it is used in any computation. That is unnecessary overhead, again lets split boxed values from primitive types. If you compute in Clojure, keeping primitive ints/shorts/bytes around has no value. You end up having type conversion to do depending on what is specified in the expression. When doing an interop call, this is when you need to be specific. Elsewhere I see no value in keeping this scheme. This way of thinking about primitive types has been sticking around for at least 35 years carrying 64/32/16/8 bit unsigned/signed int values. Maybe it's time we toss this away. I have been writing a couple of hundred thousand lines of assembly code in my professional life and I understand this model. Of course when you deal with hardware in a device driver you need these things, but in Clojure ? And with today's hardware, why stick with these data types ? To reduce memory footprint ? Ha ! Ha !, I used to work on computers with 256K of physical memory. This concern was legitimate in this prehistoric era. But today ? If you need bit manipulation in Clojure, better write a lib for this than mangling with these data types. Cheers, Ivan. On 23 October 2011 17:16, Luc Prefontaine lprefonta...@softaddicts.cawrote: CON1 - I'm buying your argumentation about consistency in Clojure maps and fixing them. Integer OBJECTS (as opposed to int primitive) should be handle as objects consistenly, not as primitive values promoted to long. CON2, CON3 and CON4 - No way, the current design choice is the good one. So many languages have been plagued with numbers of different sizes/formats for ints and floating point values, it's not a direction that Clojure should follow. These distinct types are source of many problems (overflow handling, precision problems, ...). The need for Clojure to support these things is similar to calling assembler from C. You matter about bytes, shorts and similar things at the frontier, when it's time to call a low level service, you need to be able to pass these values. By no means this implies that you have to support them in your language runtime. It complects (;) everything including computations and makes your runtime much more harder to port. It's an interop centric thing and interop is by essence not portable. It does not belong to the core of Clojure. It's better to rely on cast operators to call interop than to expect Clojure to box numeric values according to some interop convention that may vary according to the platform Clojure runs on. Luc P. On Sun, 23 Oct 2011 07:19:41 -0400 Paul Stadig p...@stadig.name wrote: On Sat, Oct 22, 2011 at 5:51 PM, Stuart Halloway stuart.hallo...@gmail.comwrote: I am dropping off this thread now. At this point I think it would be more useful for me (or someone) to expand the notes about numerics into better documentation, rather than continuing this rambling point-by-point treatment without getting all of the considerations into play at once. I hope to get that done by conj. So you are still thinking that the current behavior is OK and just needs to be documented better? Or are you saying that we need to collect the various pros and cons to decide whether the current behavior should change or remain the same? Having reviewed the thread there is lots of confusion, but from the points made it seems clear to me that the behavior should change. CON (The we should box ints as Longs (or we should keep things
Re: partial, but instead of args + additional, get additional + args
On Sun, Oct 23, 2011 at 21:25, Meikel Brandmeyer m...@kotka.de wrote: Hi, Am 22.10.2011 um 20:49 schrieb Sean Corfield: I'm starting to think there's a nice, idiomatic solution lurking somewhere that wouldn't require an extra function... The idiomatic solution is #(f % a1 a2 a3). I'm failing to see the issue with “nice” and “expressive”, but that is most likely just me. I find myself reaching for partial when I could be using #(), I even often find myself rejiggering the argument order of my own functions to make them more useful in combination with partial. But, honestly, I'm not quite sure why I have this preference. The #(...) is arguably more readable since we're shown explicitly where the argument goes, and yet I still find myself reaching for partial and comp when I can make them fit. I mean, I like the fact that partial and comp don't cause yet-another-tiny-class to be generated every time they appear in code. But that doesn't seem like reason enough. Am I just being too clever? // Ben 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
On Sun, Oct 23, 2011 at 4:01 PM, Luc Prefontaine lprefonta...@softaddicts.ca wrote: It's simpler to use one representation to port the core. You can choose the fastest/efficient one. You do not have to carry all these intermediate types with you. There are already at least two numeric types: long and BigInt. If you want to try to be blissfully unaware of any of this, then you can use promoting math (+' and friends). Adding more numeric types to the tower doesn't seems to make things more complicated in the general case, only in the interop case, or in the case that you are trying to optimize your code because it is too slow or uses too much memory. Which is what we're talking about here. You have said before that you grant there are interop cases at the edges of Clojure, and they should be kept at the edge. What we are discussing in this thread are exactly those edge/interop cases. You would never have an int or Integer unless you asked for one or got one from some Java code. It doesn't make sense to come into a discussion about interop, and say that we shouldn't let interop determine the core of the language. This thread is not about the language core. When doing an interop call, this is when you need to be specific. Elsewhere I see no value in keeping this scheme. Exactly, we're assuming in this thread that we're already at the edge doing interop, or trying to optimize our code. So any comments that assume we're not doing interop are out of scope. And with today's hardware, why stick with these data types ? To reduce memory footprint ? Ha ! Ha !, I used to work on computers with 256K of physical memory. This concern was legitimate in this prehistoric era. But today ? There are good reasons at both ends of the computing spectrum to want to be efficient with memory. Embbeded systems and mobile platforms don't necessarily have terabytes of memory to access. And on the other end of the spectrum at work, we process terabytes of data using byte arrays and byte streams, if we all of a sudden needed 8 times the memory to do the same job, it would probably be a deal killer. Similarly, we have some native JNI libraries we use that limit us to using a 32-bit JVM on some of our nodes, and we are constantly fighting OOMEs in those restricted heaps. Which is an interop case, which is the context of this thread. The core of the language can use only longs, which is fine. If you need bit manipulation in Clojure, better write a lib for this than mangling with these data types. I'd rather write that code in Clojure than Java and use it from Clojure (if that's what you're saying). And if I'm dealing with data formats, (c.f. the gloss library) it would be really inconvenient to always have things converted to longs on me. I prefer to not have a language/platform that thinks it knows what is better for me, than I do. Paul -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure 1.3 treatment of integers and longs
Hi all,
This reply is to the thread, not Luc specifically.
Thanks everyone for your feedback and input.
I have pushed 3 commits:
1) Fixes the inconsistency between the hash function used by Clojure maps (was
.hashCode) and =. Thanks Paul for the report.
2) Changes core/hash to return the result of this hashing function. Thus, it
returns a different value than does .hashCode for Integers, Shorts, Bytes and
Clojure collections. Feedback welcome.
3) Only due to the first fix, it now becomes possible to box ints to Integers
without much grief. This commit implements that for evaluation purposes, and is
not a commitment to that policy. Note well that while in the first commit the
answer is clear, on this point there is always going to be a tradeoff and there
is no 'right' answer.
Here are the issues as I see them:
First, note there is no 'following' of Java semantics as an objective. Java
semantics are that Integers are never equal to Longs, and I presume no one
wants to go back to that.
Second, boxing is a change of type, period. There is no valid complaint that
'you changed my type'. int != Integer either.
Third, there are 2 scenarios in consuming things you box in Clojure from Java:
a) You control the Java. In this case, having Clojure make everything uniform
(Longs) make things easier for you. There is no heterogeneousness regardless of
the source or manipulation of numbers, and can always expect Longs.
b) You don't control the Java. In this case you must match consuming
expectations i.e. conforming to Java promotion, types of generics etc. ***This
will *always* require vigilance and explicitness due to arithmetic conversions
etc***. Auto promotion is only one part. Note that this is true in Java as well
- while type checker may scold you, you still have to cast/coerce on mismatch.
Even with the auto box change, you are only an arithmetic operation away from
having the problem again. For instance in the original report, wrapping
.getValue with dec generates an interop mismatch again:
(let [amap {1 (dec (.getValue obj))}] …)
There is no way we are going to 'fix' that by adopting Java's numeric tower,
which is dangerous and requires static types. The bottom line is specific type
requirements on the Java side require explicit boxing on order to have correct
and non-brittle code.
The final consideration is collection equality. When Clojure autoboxes to
Longs, you get homogeneous collection contents, and thus .equals is still true
for the collection on the Java side, vs random - 'depends on where I got the
contents from and what I did with them'.
FYI - there are the RT/box functions that box as per Java. These could be
exposed in Clojure.
-
In short, having autoboxing match Java does not really free you from your
responsibility to create specific boxed types when you need them on the Java
side. I.e., Clojure can't help you.
On the flip side, when you are in charge of the Java code, Clojure's being more
consistent makes things more consistent on the other side and *does* give you
less to do to make sure things work.
I prefer what we had (auto box to Longs), but I think it matters a somewhat
less now with = consistent hashing. If we decide to revert to that we can
discuss making auto boxing of short and byte consistent.
-
In any case, those of you who still know how to use Clojure from Git can try
these commits, and please provide feedback as to its actual effects on actual
code. I think the opinion phase of this is now over :)
Thanks again for the feedback,
Rich
1)
https://github.com/clojure/clojure/commit/b5f5ba2e15dc2f20e14e05141f7de7c6a3d91179
2)
https://github.com/clojure/clojure/commit/b4a2216d78173bb81597f267b6025c74a508bd03
3)
https://github.com/clojure/clojure/commit/a2e4d1b4eaa6dad26a1a96b9e9af129a9d10
On Oct 23, 2011, at 4:01 PM, Luc Prefontaine wrote:
On Sun, 23 Oct 2011 20:31:51 +0200
Ivan Koblik ivankob...@gmail.com wrote:
Hello Luc,
In all fairness I don't see how converting ints to Integers returned
by class methods would break the abstraction. If you start talking
about portability of Clojure code, then Long is as portable as
Integer is. (In general they are not.)
It's simpler to use one representation to port the core. You can choose the
fastest/efficient one. You do not have to carry all these intermediate types
with you.
The day a 128 bits primitive type become available, there's little changes to
do to support
that. If you keep mixed types, that adds another one to the babel tower.
The problem is not to choose between ints or longs, it has to do with
carrying
all these intermediate types. Frankly aside from interop, how many are using
short ints in Clojure ? That's a leftover from the PDP-11 era.
Could you explain your position on the fact that shorts get converted
to Short? Why is it not possible to do the same for ints?
This should disappear. I think all the small
Re: partial, but instead of args + additional, get additional + args
On Sun, Oct 23, 2011 at 1:04 PM, Ben Smith-Mannschott bsmith.o...@gmail.com wrote: On Sun, Oct 23, 2011 at 21:25, Meikel Brandmeyer m...@kotka.de wrote: The idiomatic solution is #(f % a1 a2 a3). I'm failing to see the issue with “nice” and “expressive”, but that is most likely just me. I find myself reaching for partial when I could be using #() I was using #() and (fn..) extensively in my code until I noticed just how many anonymous classes were being generated (we had a scenario where we were repeatedly reloading the Clojure code - deliberately - and of course ended up with thousands of these classes loaded!). Understood it's fine in load-once-and-run scenarios. When I brought this up on IRC, several folks said they felt the comp / partial approach was nicer because it was point-free - as well as not generating new classes (new instances, yes, new classes, no - right?). Since then, I've almost eliminated the use of #() and (fn..) in our code and, whilst more verbose initially in some cases, I'm actually really liking the point-free style and it's letting me see new opportunities for refactoring and simplification that I hadn't seen previously (often triggered by encouraging me to pay more attention to argument ordering so that my functions are more composable). Given Meikel's 2009 blog post, I can understand why he might not agree, but given that we have both - and -, it does seem like we have a 'hole' - comp/partial and - go together but there's no comp/??? to go with - and we have to resort to #(f % a1 a2 a3)... -- 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: Potential bug: pmap vs chunked seqs
It isn't hard to write your own variation of pmap that does not do more parallelism than you want, regardless of whether the input sequence is chunked or not. I wrote one for a Clojure submission to the computer language benchmarks game a year or so ago. Besides avoiding unwanted parallelism for chunked sequences, it also has an option to specify the desired maximum number of parallel threads: (defn my-lazy-map [f coll] (lazy-seq (when-let [s (seq coll)] (cons (f (first s)) (my-lazy-map f (rest s)) ;; modified-pmap is like pmap from Clojure 1.1, but with only as much ;; parallelism as specified by the parameter num-threads. Uses ;; my-lazy-map instead of map from core.clj, since that version of map ;; can use unwanted additional parallelism for chunked collections, ;; like ranges. (defn modified-pmap ([num-threads f coll] (if (== num-threads 1) (map f coll) (let [n (if (= num-threads 2) (dec num-threads) 1) rets (my-lazy-map #(future (f %)) coll) step (fn step [[x xs :as vs] fs] (lazy-seq (if-let [s (seq fs)] (cons (deref x) (step xs (rest s))) (map deref vs] (step rets (drop n rets) ([num-threads f coll colls] (let [step (fn step [cs] (lazy-seq (let [ss (my-lazy-map seq cs)] (when (every? identity ss) (cons (my-lazy-map first ss) (step (my-lazy-map rest ss)))] (modified-pmap num-threads #(apply f %) (step (cons coll colls)) I'm not sure what you mean by side effects are inconsistent? If you mean side effects in terms of mutating state, then I wouldn't recommend using pmap with a function that has side effects, unless somehow you can guarantee that the order that those functions are evaluated does not matter for the final result. If you mean side effect as in how many parallel threads can be created at one time, then yes, there are differences in how pmap behaves depending upon whether it is given a chunked sequence or not. Andy On Fri, Oct 21, 2011 at 7:37 PM, Marshall T. Vandegrift llas...@gmail.comwrote: Stefan Kamphausen ska2...@googlemail.com writes: Chunked seqs are supposed to realize more elements than you consume. That's for performance reasons. But since you will only ever apply side-effect-free functions to seqs, that will make no difference, no? Sorry, yes, I'm talking about within the code of `pmap'. It creates a lazy seq of futures of application of the passed-in function to the passed-in collection via (map #(future (f %)) coll). Realizing elements of *that* seq has the side-effect of allocating/spawning a thread from the futures thread-pool. If `coll' can be turned into a chunked seq, then the futures will be realized -- and threads allocated or spawned -- in chunks of 32. If `coll' cannot be turned into chunked seq, then only (+ 2 #CPUS) threads will be allocated/spawned at a time. I think clarifying that has convinced me that this is definitely bug, just because the side-effects are inconsistent. I don't think that the chunkability (chunkiness?) of the collection argument should affect the degree of parallelism. -Marshall -- 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
bit-or arity appears limited to 2 items
The bit-or arity seems to be limited to 2, rather than more, which seems to disagree with the documentation. I get Wrong number of args (3) passed to: core$bit-or for (bit-or 1 1 1). Have I misunderstood this operation; shouldn't it take any number of values? thanks Blake -- 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
Bug in keyword handling?
Hello,
I think I've found a bug in Clojure's keyword handling. The keyword
function lets you create a keyword containing whitespace but, if
printed, the space isn't quoted or escaped, so if you print and then
read an error occurs. I would expect either the keyword creation to
fail or, when printed, the space to be escaped/quoted such that you
could print and then load the keyword.
E.g.
user= (def my-map {:key1 (keyword value one)})
#'user/my-map
user= my-map
{:key1 :value one}
user= (load-string (str my-map))
CompilerException java.lang.RuntimeException: Map literal must contain
an even number of forms, compiling:(null:1)
user=
Alasdair
--
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
On Fri, Oct 21, 2011 at 12:38 PM, daly d...@axiom-developer.org wrote: [...] Having used lisp in many different forms over the last 40 years I think that the complecting of nil to represent all three concepts is one of the most brilliant aspects of the language. In fact it is one of the key flaws of scheme, in my opinion, that they added true and false. Brilliant or clever, with all the downsides cleverness entails? I'm as guilty punning on nil as any old Common Lisper, but I have to ask myself, Is it good or just easy? There is a fourth use of nil that is also very convenient. Lisp functions return it as a default value. This makes it possible to wrap functions with functions which other languages like C++ make very difficult. [...] I agree, but that does not justify the (mis)use of nil for other purposes. The use of nil as a unified value for the many meanings leads to a lot of useful features. The context of the nil value completely defines the intended meaning. And now one _must_ provide the context for each use of nil, or, as Kent Pitman said, Several broad classes of bugs and confusions can be traced to improper attempts to recover intentional type information from representation types. http://www.nhplace.com/kent/PS/EQUAL.html So, now, instead of littering code with tests for nil (or perhaps taking that as a cue to eliminate the possibility of nil), one has complected nil and intentional context throughout. Cheers, Mike -- 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
On Fri, Oct 21, 2011 at 8:35 AM, Timothy Baldridge tbaldri...@gmail.com wrote: [...] What Rich is advocating is this: throw all the data into a hashmap. Suddenly, my SQL driver can just dump data in to the map, I can throw [...] I suspect he might have meant even more when he said, ... learn SQL, finally. SQL is more than a convenient wrapper around fopen, fread, and fwrite. Consider the possibility of expressing as many of your business rules as possible, declaratively, in SQL. Then, beyond simply dumping data into the map from the DBMS, consider that the validation functions could be queries asking the DBMS if the user input is valid. Cheers, Mike -- 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: Bug in keyword handling?
Hi Alasdair, This has been discussed at length in the past. The conclusion seems to be this: There may be situations, now or in the future, where it is desirable to create Keywords containing non-`read`able characters. Therefore, don't use Keywords for things that may contain non-`read`able characters if you want to print and read them. -Stuart Sierra 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
Re: Is Clojure Simple?
I think Clojure is simple in design, complex in implementation. Dealing with the JVM introduces all sorts of complexity. Dealing with *hardware* introduces complexity. Perfection is only possible in the abstract. Compromises are always needed, and Clojure generally makes good ones. But there may be languages which make different compromises that offer an advantage in certain situations. -Stuart Sierra 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
Re: Clojure 1.3 treatment of integers and longs
As a reminder, you don't need Git to use the latest development version of Clojure. Just set your Clojure dependency version to 1.4.0-master-SNAPSHOT and add Sonatype to your Maven repositories. Detailed instructions here: http://dev.clojure.org/display/doc/Maven+Settings+and+Repositories -Stuart Sierra 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
Re: bit-or arity appears limited to 2 items
On Fri, Oct 21, 2011 at 4:12 PM, rugby_road cabjh...@embarqmail.com wrote:
The bit-or arity seems to be limited to 2, rather than more, which
seems to disagree with the documentation. I get Wrong number of args
(3) passed to: core$bit-or for (bit-or 1 1 1). Have I misunderstood
this operation; shouldn't it take any number of values?
Clojure 1.3.0:
user= (doc bit-or)
-
clojure.core/bit-or
([x y] [x y more])
Bitwise or
nil
user= (bit-or 1 1 1)
1
user= *clojure-version*
{:major 1, :minor 3, :incremental 0, :qualifier nil}
Clojure 1.2.1:
user= (doc bit-or)
-
clojure.core/bit-or
([x y])
Bitwise or
nil
user= (bit-or 1 1 1)
java.lang.IllegalArgumentException: Wrong number of args (3) passed
to: core$bit-or (NO_SOURCE_FILE:2)
user= *clojure-version*
{:major 1, :minor 2, :incremental 1, :qualifier }
So it looks like the ability to take more than two arguments was added
in 1.3.0 (and the doc-string agrees).
--
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: partial, but instead of args + additional, get additional + args
On Sun, Oct 23, 2011 at 23:53, Sean Corfield seancorfi...@gmail.com wrote: On Sun, Oct 23, 2011 at 1:04 PM, Ben Smith-Mannschott bsmith.o...@gmail.com wrote: On Sun, Oct 23, 2011 at 21:25, Meikel Brandmeyer m...@kotka.de wrote: The idiomatic solution is #(f % a1 a2 a3). I'm failing to see the issue with “nice” and “expressive”, but that is most likely just me. I find myself reaching for partial when I could be using #() I was using #() and (fn..) extensively in my code until I noticed just how many anonymous classes were being generated (we had a scenario where we were repeatedly reloading the Clojure code - deliberately - and of course ended up with thousands of these classes loaded!). Understood it's fine in load-once-and-run scenarios. When I brought this up on IRC, several folks said they felt the comp / partial approach was nicer because it was point-free - as well as not generating new classes (new instances, yes, new classes, no - right?). Since then, I've almost eliminated the use of #() and (fn..) in our code and, whilst more verbose initially in some cases, I'm actually really liking the point-free style and it's letting me see new opportunities for refactoring and simplification that I hadn't seen previously (often triggered by encouraging me to pay more attention to argument ordering so that my functions are more composable). Given Meikel's 2009 blog post, I can understand why he might not agree, but given that we have both - and -, it does seem like we have a 'hole' - comp/partial and - go together but there's no comp/??? to go with - and we have to resort to #(f % a1 a2 a3)... I propose partail ;-) While partial fills up the arguments from the front, partail fills up the arguments from the back (the *tail*). Plus, the spellings are so similar that it would cause no end of confusion, particularly for people like me that swap letters every once in a while, even when we don't mean to. Ok, Cute name, but not a good name. Anyone got a better one? // Ben -- 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 -- 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
