Indirect inline types as a middle ground

[Michael van Acken]

Am Sa., 11. Mai 2019 um 12:21 Uhr schrieb Michael van Acken <
michael.van.acken at gmail.com>:

> [...]
>
> 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.
>

[Trying again to sort my vague thoughts:] For some reason, I see value
in two types inline_V and indirect_V, that have a bijective mapping
between them, and where the indirect type is sufficiently like a
reference to take part in collection APIs.

Maybe it's a throwback to my Modula-2/Oberon-2 days long past, with
POINTER, dereference operator, and VAR parameters.  Maybe it's my
subconsciousness seeing a way towards a future with less nulls, and
hopefully less NPEs.

For me, the single value point of the oh so innocent looking "null"
literal is the most widely interpreted primitive value of them all.
It's like a blank canvas where, at each point of use, an application
must paint its own picture.  On the other hand, Clojure has many
interpretations of nil/null depending on context (empty seq, empty
collection, logical false, receiver of a protocol function, etc.), and
this multitude works quite nicely for me.  I dislike the former, but
like the latter.  This is a contradiction I cannot really resolve.

Anyway, when I read the "Nullable Value Types in L-World" document
https://mail.openjdk.java.net/pipermail/valhalla-spec-experts/2018-November/000784.html
last year, I had two initial reactions: 1) I don't understand even a
small part of it, and 2) could this be a way to have the JVM (in some
situations) provide a fixed interpretation of "null_type null" for me?

Scenario: The inline (value) type V is the starting point, the `wrap`
function takes it to its indirect inline sibling, and the `unwrap`
function takes it back to V again.  With the two functions being
inverses of each other, I'm only looking at the case where `unwrap`
encounters a "null pointer", e.g. taken from a default-valued
variable.

a) If V has a designated inline value interpretation for the null
pointer, then `unwrap` produces this special inline value as a result.

b) Lacking such a designated interpretation, it interprets the
situation as an invalid program state and raises an appropriate
exception (maybe NPE).

In both cases the JVM would not surface a null reference, but instead
decide itself: either it produces a perfectly valid inline value, the
"inline value null", or it declares the operation a program error.

(In situations where the "null_type null" is really required, there is
the option for the application to use the inline-in-reference
construction, like int-in-Integer.)

Having written all this, I think the crucial point of such an
indirect_V construction is, that a null pointer within it is not
directly visible to the application.  It is an implementation detail
that is always subject to the interpretation of the `wrap` and
`unwrap` functions.  But the indirect_V type would have the same
observable value set as the inline_V type.

-- mva