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

Reply via email to