Re: how can I dispatch on "[[F" ..
On Fri, 14 Jan 2011 01:48:43 -0800 (PST) Meikel Brandmeyer wrote: > Or: > > (defmethod foo (clojure.lang.RT/classForName "[[F") > ...) But isn't this too dependent on the actual implementation? I would think that "[[F" is an implementation detail of the JVM. regards, Marek -- 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: how can I dispatch on "[[F" ..
On Sat, Jan 15, 2011 at 5:17 AM, Marek Kubica wrote: > On Fri, 14 Jan 2011 01:48:43 -0800 (PST) > Meikel Brandmeyer wrote: > >> Or: >> >> (defmethod foo (clojure.lang.RT/classForName "[[F") >> ...) > > But isn't this too dependent on the actual implementation? I would > think that "[[F" is an implementation detail of the JVM. It's a classname, even if not one you could use yourself. I'm pretty sure it has to be stable for multiple reasons, not least of which being for serialization (and, thus, RMI among other things) to work correctly between implementations. It will be in class files as the classes of various data members and return types and such. There are probably other places it appears, too. I doubt it could be different in some implementations any more than "java.lang.String" could be. That being said, the method I proposed for obtaining a reference to the class does not depend on this. :) -- 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: fns taking primitives support only 4 or fewer args
Ken Wesson wrote: > The interfaces are needed only if the function is passed around as an > object or dynamically rebound; if it's just called at a few fixed > sites, those calls can be directly to a known class. The class names of function implementations seem to be a Clojure implementation detail. It has changed over the years, classes used to contain a unique numeric suffix. Closures don't have obvious names. If a function gets wrapped in something like a primitive-aware memoize, the client call sites shouldn't need to be recompiled. So I don't think a direct call to the implementation class is enough. > Even then, couldn't the compiler generate the needed interfaces for a > specific Clojure project on the fly along with the appropriate calls? I don't see why it couldn't. Actually I just hacked the Clojure compiler to do that, removed the limitation on 4 args, and removed all of the static IFn$*** classes, and it seemed to work fine. The static IFn$*** classes probably have some small value though. For instance, if some Java code is passed a dynamically created fn, which it knows to have a primitive interface, it can cast it to one of these pre-defined interfaces, whereas if the interfaces were only created dynamically, it wouldn't be easy to get the Java to compile in that case. 1.3 is currently an alpha, I suspect that this first stab at primitive args is currently deliberately conservative. -- 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: fns taking primitives support only 4 or fewer args
On Sat, Jan 15, 2011 at 6:44 AM, David Powell wrote: > Ken Wesson wrote: >> Even then, couldn't the compiler generate the needed interfaces for a >> specific Clojure project on the fly along with the appropriate calls? > > I don't see why it couldn't. Actually I just hacked the Clojure > compiler to do that, removed the limitation on 4 args, and removed all > of the static IFn$*** classes, and it seemed to work fine. > > The static IFn$*** classes probably have some small value though. For > instance, if some Java code is passed a dynamically created fn, which > it knows to have a primitive interface, it can cast it to one of these > pre-defined interfaces, whereas if the interfaces were only created > dynamically, it wouldn't be easy to get the Java to compile in that > case. I think this can be dealt with easily enough. If callability from Java is desired, you could give the interface an explicit name, in effect, using existing facilities such as records and protocols and gen-class; or write an explicit interface in Java and implement it using proxy; or etc. -- 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: Enhanced Primitive Support Syntax
On Jan 15, 2:40 am, Armando Blancas wrote: > They used to give you compile switches for that kind of stuff, not > hope and wholesome wishes. Seems like every performance improvements > makes the language more complex, uglier or both. > I don't feel strongly about integer limits at all and am always surprised when this comes up. I did scientific programming on a 32 bit platform for several years and never met anyone who hit big problems with fixed size integers. For illustration, Long.max is: 9 223 372 036 854 775 807 which is so much bigger than I was used to. I know encryption requires BigInteger but I have yet to see a native clojure encryption library. It would help people like me understand the debate if some mainstream examples of applications requiring (seamless) BigInteger support could be identified. Saul -- 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: how can I dispatch on "[[F" ..
It's in the Java spec. http://java.sun.com/docs/books/jls/third_edition/html/arrays.html#10.8 -- 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: Enhanced Primitive Support Syntax
I'm going to re-organise this a bit… > On Jan 14, 2:40 pm, Stuart Sierra wrote: >> Debatable it is, endlessly. ;) So Clojure committers made a choice. >> Hopefully, they have made a choice that has: I agree that they've made a choice, and I really don't want to be too critical here. However, since Clojure 1.3 is still in an alpha stage, maybe this discussion can still contribute something. Maybe what I'm saying is that I want to stay constructive and that there's maybe still time to be constructive. >> >> * a small positive effect (better performance with less effort) on a >> majority of users >> >> * a small negative effect (worse performance, extra effort) on a minority These goals are good, but I don't know that the approach taken achieves them. In my experience, errors are the problem and we should be avoiding them, almost at all costs. Numbers are confusing to people. Numbers approximated on a computer are far more confusing. How many times do you see threads discussing how a compiler is buggy because it can't divide two numbers and get the right answer? I've been doing this stuff for years and I can come up with an awful lot of amusing and/or horribly nasty examples. But I don't think this needs to be re-established. Given my experience I *strongly* lean towards not making a 'mistake' due to compiler optimisations. In other words, I'd be very annoyed, and I'd expect others to be annoyed too, if a numerical error was introduced to one of my programs because of an unexpected, silent, compiler optimisation. Secondly, Clojure has already established that we will use type annotations to signal to the compiler what's what. When we annotate, we are relaxing our requirements on the compiler to not make a mistake by assuming that responsibility ourselves. I would suggest the following: 1) if there's type annotation on both values of, say, an addition, then the optimised version can be used. If there isn't, or the compiler isn't sure, then use safe operations. 2) if the compiler isn't cooperating (because it isn't sure what's going on) we should be helping it by again assuming the responsibility of being right and marking the operator, say with a tick. And yes, this likely has problems too. I'm not saying that this is an issue with easy solutions. We're heading for a hodgepodge of annotation purposes, some for optimisation, some for correctness (and one of these days I'll mention what I think of the @/deref thing :-) And now we're pretty much guaranteed ugly code no matter what. Though I'd prefer no ugliness, I'd trade ugly code for speed, but I'd rather not for correctness. And there's a practical problem with mixed annotation purposes. If you want to track down a bug you can't just remove all annotations temporarily. You'd have to remove some and add others. Not looking forward to that. Maybe a macro: make-this-safe could be written. Hmm. Maybe a 'defn-safe' would be something to think about??? This is also the kind of thing that you just can't fix later. Imagine how we'll feel in ten or twenty years about this decision. >> >> -S > On 2011-01-14, at 8:40 PM, Armando Blancas wrote: > They used to give you compile switches for that kind of stuff, not > hope and wholesome wishes. Seems like every performance improvements > makes the language more complex, uglier or both. > Compiler switches were/are problematic too, but at least they are explicit and have to be *added*. Cheers, Bob Bob Hutchison Recursive Design Inc. http://www.recursive.ca/ weblog: http://xampl.com/so -- 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: Enhanced Primitive Support Syntax
Hi, just for the record: from what I have done in the past I wholeheartedly agree with Bob. Of course the developers of Clojure have the final say on this. It's just my 2ct. Kind regards, Stefan -- 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: Enhanced Primitive Support Syntax
Bob Hutchison said: > In other words, I'd be very > annoyed, and I'd expect others to be annoyed too, if a numerical > error was introduced to one of my programs because of an unexpected, silent, > compiler optimisation. Just to be clear, Clojure 1.3-alpha does not introduce numerical errors, unless you explicitly ask for them; it throws a RuntimeException - which I guess is analogous to it being a dynamically-typed language and throwing RuntimeExceptions to signal type errors. user=> (* 1000 1000) ArithmeticException integer overflow clojure.lang.Numbers.throwIntOverflow (Numbers.java:1583) user=> (*' 1000 1000) 100N user=> (* 1000 1000N) 100N user=> (unchecked-multiply 1000 1000) 1864712049423024128 -- 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: Enhanced Primitive Support Syntax
On Jan 15, 2011, at 8:29 AM, Saul Hazledine wrote: > It would help people like me understand the debate if some mainstream > examples of applications requiring (seamless) BigInteger support could > be identified. I doubt that many will consider this "mainstream," but I evolve programs using genetic programming techniques and I've found that in this context BigIntegers can arise in all sorts of unexpected and weird and wonderful and sometimes adaptive ways. I still haven't figured out exactly what the 1.3 changes will mean for this work -- maybe it'll be fine or even better -- but I've liked not having to think about integer sizes much at all previously (as in Common Lisp, where the handling of complex numbers is also nice). -Lee -- 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: Enhanced Primitive Support Syntax
I think this is looking at the situation backwards. I don't want BigInts, why should I want *them*? Nor longs or whatever for that matter. What I want is a numerical tower and a language that can handle it correctly, without blowing up, and if possible with clean code. I can type 9223372036854775807 or something bigger in a spreadsheet and get 9.22337203685478E+018, and take it from there. Now, I don't know if spreadsheet programmers *want* doubles, but something correct (if less precise) must be done depending on what *I, the user* wants to do. Now we face the choice of putting limits on what our users can do, use a different set of operators, or decide that we "want" BigInts. Again, this isn't about wanting bigints, that's a red herring. Part of the problem is the complex, confusing, and sometimes quite mysterious Type System that's been creeping into Clojure for the sake of performance. Another is the conflicted attitude of being an untyped language: a kind of guilty pleasure with the remorse it brings of all those reflective calls and boxing/unboxing, whose negative effects on performance supposedly makes the language lose credibility. If a Type System is what it takes to establish Clojure in the server/ enterprise market, maybe this is be start of a family of languages, with one simple and elegant and another pragmatic and subordinated to the demands of business, a la Microsoft C++ with COM or something that ugly. On Jan 15, 8:48 am, Lee Spector wrote: > On Jan 15, 2011, at 8:29 AM, Saul Hazledine wrote: > > > It would help people like me understand the debate if some mainstream > > examples of applications requiring (seamless) BigInteger support could > > be identified. > > I doubt that many will consider this "mainstream," but I evolve programs > using genetic programming techniques and I've found that in this context > BigIntegers can arise in all sorts of unexpected and weird and wonderful and > sometimes adaptive ways. > > I still haven't figured out exactly what the 1.3 changes will mean for this > work -- maybe it'll be fine or even better -- but I've liked not having to > think about integer sizes much at all previously (as in Common Lisp, where > the handling of complex numbers is also nice). > > -Lee -- 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
Grabbing Rotten Tomatoes movie ratings in clojure
Sharing my first useful Clojure program. Feedback welcome. http://bit.ly/clojure-rotten-tomatoes -- 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: Enhanced Primitive Support Syntax
> In my experience, errors are the problem and we should be avoiding them, > almost at all costs. This debate always starts by conflating three things into two, and then goes downhill from there. :-( It isn't (a) safe/slow vs. (b) unsafe/fast. It is (a) unsafe/incorrect value on overflow/fastest/unifiable* vs. (b) safe/error on overflow/fast/unifiable vs. (c) safe/promoting on overflow/slow/not-unifiable *unifiable: able to deliver same semantics for primitives and objects We have thought about this quite a bit, and an argument from one axis only (e.g safe/unsafe) that doesn't even mention some of the other axes is not likely to be persuasive. Would be more interesting to see a new axis we haven't thought of... Stu Stuart Halloway Clojure/core http://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: Enhanced Primitive Support Syntax
> I think this is looking at the situation backwards. I don't want > BigInts, why should I want *them*? Nor longs or whatever for that > matter. What I want is a numerical tower and a language that can > handle it correctly, without blowing up, and if possible with clean > code. I can type 9223372036854775807 or something bigger in a > spreadsheet and get 9.22337203685478E+018, and take it from there. > Now, I don't know if spreadsheet programmers *want* doubles, but > something correct (if less precise) must be done depending on what *I, > the user* wants to do. The spreadsheet example may be a useful one. Clojure is a language you could write a spreadsheet in. Would you want to use a spreadsheet written entirely in a JVM language that did not provide access to the primitives? > Now we face the choice of putting limits on what our users can do, use > a different set of operators, or decide that we "want" BigInts. Again, > this isn't about wanting bigints, that's a red herring. Part of the > problem is the complex, confusing, and sometimes quite mysterious Type > System that's been creeping into Clojure for the sake of performance. Clojure is not getting a type system. nor is the behavior in 1.3 complex. It can be confusing, because it is addressing a multifaceted problem, and it certainly is mysterious, because (1) we haven't spent enough effort documenting it, and (2) lots of people have misdocumented it. I'll make a documentation update higher priority; hopefully that will help. > Another is the conflicted attitude of being an untyped language: a > kind of guilty pleasure with the remorse it brings of all those > reflective calls and boxing/unboxing, whose negative effects on > performance supposedly makes the language lose credibility. The Clojure design process is not about achieving credibility, it is about solving problems. Credibility has followed, and will continue to follow, to the extent that Clojure solves problems well. Stu Stuart Halloway Clojure/core http://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
thinking parallel programming
Guy Steele recently gave a talk about thinking about parallel programming. For those of us who are looking at Clojure in a parallel setting (e.g. MPI, Hadoop) this might be of interest: http://www.infoq.com/presentations/Thinking-Parallel-Programming -- 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: Enhanced Primitive Support Syntax
On Sat, Jan 15, 2011 at 1:06 PM, Stuart Halloway wrote: > We have thought about this quite a bit, and an argument from one axis only > (e.g safe/unsafe) that doesn't even mention some of the other axes is not > likely to be persuasive. Would be more interesting to see a new axis we > haven't thought of... Here's an axis that hasn't gotten much discussion: How evident is the behavior of Clojure code, and what features help and hinder this clarity? Clojure is a dynamically typed language, which means that generally speaking, it is not obvious what the type of a given variable is, since there aren't annotations immediately prior to the variable telling you what it must be. Similarly, a Clojure IDE does not offer any way to to "hover" over a variable and see what the type is. There is a lot of freedom that comes with this, but the cost is that a dynamic programmer must be careful to document in some way what kinds of things are acceptable inputs, and what kinds of promises are made of the outputs. The compiler can't check this, so it's up to the programmer. As Clojure programmers, we take on the responsibility of tracking a certain amount of "unseen information" that isn't readily evident from the code itself, but there's a limit to how much responsibility programmers can take on before programs become brittle, so new features should take this "axis" into account. Primitives are especially problematic because there is no good way to determine whether something is a primitive or not. Consider the following interactions in the 1.1 REPL: user> (type 1) java.lang.Integer user> (type (int 1)) java.lang.Integer Any features involving primitives should be assessed from the standpoint that it is extremely difficult to know from looking at code whether something is a primitive or not. Many of the new features (e.g., static functions can now return primitives, literals are primitives, but numbers that get stored in collections or cross certain kinds of function boundaries are not), means that you'll frequently end up with a mixture of primitives and non-primitives, and it won't always be obvious which is which. When designing math operators that behave one way for longs and another for bigints, one question that needs to be asked is: "How apparent will it be whether a variable represents a long or a bigint? If it's not apparent, how will the programmer know which behavior to expect? Is there any tooling that can help make this more discoverable?" One possibility is that Clojure programmers will need to evolve ways to track this information, perhaps by explicitly commenting in code whether a function can gracefully handle both longs and bigints. On the other hand, there's already a history in Clojure and similar languages of just documenting certain vars as "numbers" without needing to get more precise than that, so this could be a painful transition for many programmers who are not used to thinking about specifying their numeric types in greater detail than that. Because it's difficult to do "typeflow analysis" within a dynamically-typed language as Clojure, this clarity axis also comes into play when thinking about what sorts of burdens are going to be placed on library developers. As a case in point, I developed the expt function in clojure.contrib.math because I was surprised when I first came to Clojure that no generic exponentiation operator existed in the language. The expt in contrib handles all of Clojure's numeric types seamlessly. But what am I supposed to do with expt in Clojure 1.3? New expectations are being created with the new model -- some people will expect expt with primitives to return primitives; some will expect computation with longs to return bigints when necessary, since exponentiation frequently overflows. Do I need to provide an expt and expt' function to make both camps happy? (For that matter, is there even a way to overload expt for both primitive longs and primitive doubles, or do I need to make separate expt-long and expt-double functions?) Are we going to see a proliferation of variations for all mathematical functions once we start going down this road? This is an axis I think about a lot, and I hope this is something that the Clojure dev team is carefully considering as well. -- 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: Enhanced Primitive Support Syntax
On Sat, Jan 15, 2011 at 9:40 PM, Mark Engelberg wrote: > On Sat, Jan 15, 2011 at 1:06 PM, Stuart Halloway > wrote: >> We have thought about this quite a bit, and an argument from one axis only >> (e.g safe/unsafe) that doesn't even mention some of the other axes is not >> likely to be persuasive. Would be more interesting to see a new axis we >> haven't thought of... > > Here's an axis that hasn't gotten much discussion: How evident is the > behavior of Clojure code, and what features help and hinder this > clarity? [massive snip] > This is an axis I think about a lot, and I hope this is something that > the Clojure dev team is carefully considering as well. +1 to all of that. -- 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: Enhanced Primitive Support Syntax
On Jan 15, 2011, at 4:04 PM, Stuart Halloway wrote: > I'll make a documentation update higher priority; hopefully that will help. This should help. I feel like the discussion is going in circles because there's no single, official source that summarizes exactly what is happening with numerics in 1.3. (I know about http://www.assembla.com/wiki/show/clojure/Enhanced_Primitive_Support, but it's terse and a bit confusing.) -- 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: Enhanced Primitive Support Syntax
> (a) unsafe/incorrect value on overflow/fastest/unifiable* vs. > (b) safe/error on overflow/fast/unifiable vs. > (c) safe/promoting on overflow/slow/not-unifiable If I understand correctly, the issue with auto-promotion is that we have to box the output of an operation even if it turns out to fit in a long, since the compiler must specify whether the result will be long or Object. This is probably a stupid question, but since Clojure is already testing for overflow in (b) to throw an exception, would it be possible to jump into an alternative (c)-type compilation of the function just-in-time to promote on overflow instead? It seems like this could achieve the performance of (b) while still allowing for auto-promotion (albeit perhaps with a performance hit in that case, code bloat, compromises about how many versions to compile, etc.). For what it's worth, I'm personally happy with the approach of the current alpha. -- 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: thinking parallel programming
In the Hacker News discussion about that talk, someone posted a link to another talk by Guy Steele on the same topic: http://vimeo.com/6624203 ... where he covers the material in somewhat greater depth (the downside being that by the 30-minute mark, I was struggling to keep up with the flow of ideas). I found it to be a nice complement to the talk at infoq. Also, some interesting questions were fielded at the end. On Jan 15, 4:50 pm, Tim Daly wrote: > Guy Steele recently gave a talk about thinking about parallel programming. > > For those of us who are looking at Clojure in a parallel setting (e.g. > MPI, Hadoop) > this might be of interest: > > http://www.infoq.com/presentations/Thinking-Parallel-Programming -- 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
