changes in use of type hints / ClojureCLR

[David Miller]

Cranking through the changes in 1.3.0. Working on :static. (Even
if :static is going away, much of the problem remains with the new
primitive arg/ret types introduced this week.)

I need feedback on whether I am perceiving the most recent moves
correctly, and suggestions on how best to handle the problems that
arise for ClojureCLR.


JVM: primitive === int, double, long, etc. Wrapper = Integer,
Double, etc. Ne'er the twain shall meet, mostly, except via un/
boxing.

CLR: no wrappers, so no real distinction between int and Int32.
Difference boxing model helps hide the differences. I have had to
figure out how to translate all the Double.valueOf sort of code, deal
with the interop, etc. Somehow, at present, it works.

When I translate clojure code (core.clj and company), I translate
Integer type hints into Int32, etc., and everything magically works.

However, I have no real distinction between int/Int32, as opposed to
the JVM int/Integer.

In the new FnExpr/FnMethod code, we now have a distinction on type
hints on parameters: primitive only if :static (in earlier versions)
and now only long/double.

Now type hints on parameters serve two purposes: type hints for
interop to avoid reflection AND indication that a primitive interface
method is desired.

Correct?

If so, then is it suggested that in code intended for ClojureCLR, that
use of the type decorations int, double, long, etc. on regular
function parameters/return be reserved for primitive interface method
usage and and Int32, Int64, Single, Double, etc. be used when only the
type hint is intended?

<whine>now I get to track whether an Int64 as a param type started
life as a 'long' or an Int64 hint. Sigh. Grumble. </whine>

-David AKA Ginger Rogers (*)


(*) Ginger had to dance the same moves as Fred Astaire, only backwards
and wearing high heels. Of course, we know who was leading.

[Rich Hickey]

That's funny!

On the JVM side people haven't been using int/long etc as type hints
on fn args, as they aren't supported, and rarely use Integer, Long
etc, as few methods take the boxed types. If people have been doing
Int32 etc arg hints on the CLR they have had a feature (primitive
hinting on fn args) that the Java users don't have, and that really
doesn't make sense - i.e. those fns do not in fact take Int32s but
Objects. The fact that Int32s can be treated as Objects is a CLR
slight of hand. As an argument type (and many other places, e.g.
generics) the distinction becomes clear, e.g. you can't pass null to
an Int32-taking method.

So, yes, let's reserve int/long/etc for primitives, and Int32 etc too.
Thus, their use as type hints for args should only be supported for
fns taking primitives, and other disambiguation circumstances will
need to be resolved by coercion at the point of call (as it is not on
the Java side). I saw one instance of Integer type hint in core.clj
and it should be removed.

Rich

[David Miller]

I'm happy to go with your solution. It will force me to stop the
punning (i.e. lying) I've been doing.

I'm the main culprit in replacing ^Integer and the like hints with
^Int32 hints, mostly to minimize the changes I have to make to the
bootstrap clj code. It may have been a pun, but it worked for type
hints. Now that contracts are being stated in fn arglists, I'll have
to be honest.

-David