On Thu, Dec 15, 2011 at 6:33 PM, David Nolen <dnolen.li...@gmail.com> wrote: > On Thu, Dec 15, 2011 at 6:19 PM, Cedric Greevey <cgree...@gmail.com> wrote: >> >> I don't see any logical reason why a function taking only >> non-primitive arguments cannot have a primitive return value. > > > You need a JVM method signature for every n number of object arguments + the > supported primitive return type. So more interfaces would have to be defined > for the object args only case. Personally I don't see the advantage given > the use case here is high performance helper fns.
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? In that case, can't the compiler eschew using an interface and just call the function directly? For that matter, can't it just generate both a "1.2 version" of the function and a "1.3 version", with the IFn interface methods calling the "1.2 version", and direct use at a call site calling the "1.3 version" directly without going through an interface? That makes functions with primitive args and/or returns nondynamic at such call sites, but that already seems to be at least partially the case, necessitating recompiling the calling functions at least when the type signature changes. The indirect call case tends to mean HOF use, which tends to mean it's being run over a collection's members, which tends to mean unboxing gets done anyway, so the "1.2 version" being used in such contexts wouldn't be a disadvantage. (And a closure like #(foo 1 2 %) would compile into a call to the "1.3 version", if existent, of foo; only the % argument then needs unboxing, while the 1 and 2 can be compiled and passed in as primitives). The one case I see as being less efficient might be (let [f (if some-condition f1 f2)] (f some-primitive-arg)) where both f1 and f2 take a primitive arg. Right now that might be efficient, whereas with the above suggestion it would call the "1.2 version" and some-primitive-arg would get boxed and unboxed. But I think that case is comparatively rare, relative to invocation of a statically-determined function that uses and/or returns primitives. -- 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