Indirect inline types as a middle ground

[Michael van Acken]

For quite some time I have been working on a compiler for a Clojure
variant with predictable primitive performance, with an eye on future
value types (now inline types).

I started out by replacing the Clojure numerics stack with the Java
numerics stack, in the process dropping support of e.g. decimal or
rational numbers, but on the other hand gaining support for types like
primitive int, float, boolean, etc.

Next was the question, how primitive values can participate in (erased
generics) collections like map, vector, set, etc.  My minimal approach
consists of two operations, one to take a primitive/inline value to
its indirect representation, and one to take the indirect
representation back to its inline value.  Something like f: int ->
indirect_int and its inverse g: indirect_int -> int, where
indirect_int does not include null.  In practice indirect_int is
mapped to plain old "Integer-but-never-null", of course.

Using this as a template, it appears to me that there is a progression
from inline_V to indirect_V_without_null to indirect_V_with_null.  The
indirect_V in the middle takes on some properties from either of its
siblings: from its reference-like kin the indirection part, from its
inline-sibling the value set.  This halfway type would suffice to
participate in a lot of collection APIs.

Spinning the hypothecial "indirect int" example further:
`(indirect_int)null` would fail, in contrast to `(Integer)null`.  A `x
= new indirect_int[8]` would produce a null filled array where `x[0]`
would fail unless there was a prior assignment to `x[0]`.  On the
other hand, such an array would gain the logical operation
`containsKey`, in analogy to HashMap.

I believe one can talk about the concept "indirection" in isolation,
without immediately taking the "null" part on board as well.  Don't
know if it provides enough value to stand on its own, though.

-- mva