On Thu, Dec 15, 2011 at 7:29 PM, David Nolen <dnolen.li...@gmail.com> wrote: > On Thu, Dec 15, 2011 at 7:14 PM, Cedric Greevey <cgree...@gmail.com> wrote: >> >> For helper fns, it's unlikely to be necessary to use the function >> widely in generic contexts, i.e. in a first-class manner, right? > > fns with prim args/return support already do this. When not used higher > order if the compiler can infer the right interface to use at a call site it > will use it. Otherwise it calls the generic version.
In that case, I don't see the need for the interface in the non-higher-order case. It could just create a Java method of some class that implements the primitive-ized version of the fn, and compile a direct invocation to that method of that class at the call site without using any interface. And that gets rid of any limitation that is not a JVM-based limitation of a Java method. I'm pretty sure it would allow a lot more than 4 arguments, in particular. > To be clear there is no "unboxing". If something becomes boxed, it must be > manually unboxed by you. If it's passed to a function or, via interop, Java method that expects a primitive, it seems to be unboxed: (Math/sqrt 2.0) 1.4142135623730951 And just to be sure the argument to Math/sqrt is a Double and not a double: (Math/sqrt (Double. 2.0)) 1.4142135623730951 No "no matching method" error and no Math.sqrt(Double) overload listed in the javadocs. (Though I notice that (Double. 2) hurls with a "no matching ctor" message -- I think that worked under 1.2? So it's not doing conversions, even widening conversions, of numeric types to resolve interop calls; hmm.) > As far needing to recompile callers of changed prim fns I think this is a > case of c'est la vie until someone volunteers to fix it (if that's > possible). Oh, I think that probably can't be avoided, but in that case there's little point in not ditching the interface and calling the fn class directly at nondynamic call sites. Again, cases where the function is variable but the arguments don't come pre-boxed by being pulled out of a coll are passing rare. We should be optimizing for the common case. -- 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
