On 21 June 2010 16:52, Rich Hickey <richhic...@gmail.com> wrote: > I've added the speculative analysis required to detect when recur arguments > fail to match the type of primitive loop locals, and recompile the loop with > those loop args boxed. When *warn-on-reflection* is true it will issue a > report that this is happening and why.
Ah, this is absolutely fantastic! I find my general stance on the issue matches Mark's summary pretty much exactly and to be totally blissfully happy, I'd prefer the primes to be moved over to the non-promoting ops (which I realise would cause autoboxing to appear wherever any of the non-primed ops appear -- but now there's the warning and thus no inexplicable slowdowns). In fact, my understanding is that any locals participating in arithmetic which directly or indirectly (i.e. because of interaction with other locals) involves an unhinted parameter to the function the local is declared in will now be autoboxed; does using the non-promoting operators by default have any intrinsic benefits in this situation? Note that after this commit I think I'm guaranteed to be extremely happy about Clojure's new arithmetic. Thanks! Sincerely, Michał -- 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
