<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<br>
<font size="4"><font face="monospace"></font></font>
<blockquote type="cite" cite="mid:799cc618-a3c6-2b8d-c03f-d154e5bf6107@oracle.com"><font size="4"><font face="monospace">
<blockquote type="cite">
<div class="gmail_default" style="color:rgb(7,55,99)"><span style="font-family:monospace"><font size="4">If this is
possible, maybe Valhalla's Java could have a
user-model like this:<br>
</font></span></div>
</blockquote>
<br>
You should probably start with what problem you are trying to
solve. </font></font><br>
</blockquote>
<br>
The poster offered the following clarifications:<br>
<br>
<blockquote type="cite"><span style="font-family:monospace"><font size="4">The problem it's trying to solve is to remove the
.val and .ref operators/knobs/concepts from the user-model
without any loss of performance or loss of control over
nullability, zeroness or atomicity. In other words, the
objective is to take Kevin's ref-by-default idea one step
further.</font></span>
<div>
<div style="color:rgb(7,55,99)" class="gmail_default"><span style="font-family:monospace"><font size="4"><br>
</font></span></div>
<div style="color:rgb(7,55,99)" class="gmail_default"><span style="font-family:monospace"><font size="4"><br>
</font></span></div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div style="color:rgb(7,55,99)" class="gmail_default"><span style="font-family:monospace"><font size="4">
<span class="gmail_default" style="color:rgb(7,55,99)"></span>In
theory, we could construct the union type int|Null, but
this type doesn't have a practical representation in
memory, ...</font></span></div>
</blockquote>
<span style="font-family:monospace"><font size="4"><br>
</font></span></div>
<div><span style="font-family:monospace"><font size="4"><br>
</font></span></div>
<span style="font-family:monospace"><font size="4"><span class="gmail_default" style="color:rgb(7,55,99)">Would it be
possible to have a value-class give rise to these 3
hidden/runtime-only companion-types <font size="4"><span class="gmail_default" style="color:rgb(7,55,99)"> on the
heap</span></font>:</span></font></span>
<div><span style="font-family:monospace"><font size="4"><span class="gmail_default" style="color:rgb(7,55,99)"><br>
</span></font></span></div>
<div><span style="font-family:monospace"><font size="4"><span class="gmail_default" style="color:rgb(7,55,99)">
RefType - reference to a value-instance or no-reference
(null)<br>
</span></font></span></div>
<div><span style="font-family:monospace"><font size="4"><span class="gmail_default" style="color:rgb(7,55,99)">
ValType - inlined [value-instance-fields]<br>
</span></font></span></div>
<div><span style="font-family:monospace"><font size="4"><span class="gmail_default" style="color:rgb(7,55,99)">
ValType? - inlined [nullability-boolean +
<font size="4"><span class="gmail_default" style="color:rgb(7,55,99)">value-instance-fields]</span></font></span></font></span></div>
<div><span style="font-family:monospace"><font size="4"><span class="gmail_default" style="color:rgb(7,55,99)"><font size="4"><span class="gmail_default" style="color:rgb(7,55,99)"><br>
</span></font></span></font></span></div>
<div><span style="font-family:monospace"><font size="4"><span class="gmail_default" style="color:rgb(7,55,99)"><font size="4"><span class="gmail_default" style="color:rgb(7,55,99)">Then, the runtime could
transparently choose between RefType|ValType for
non-nullable variables or between RefType|ValType? for
nullable variables, depending on hardware, bitSize,
zeroness and atomicity constraints<font size="4"><span class="gmail_default" style="color:rgb(7,55,99)"><font size="4"><span class="gmail_default" style="color:rgb(7,55,99)">, as explained by
the ternary expression in my previous email</span></font></span></font>.
Of course, since ValType? has a higher bitSize than
ValType, nullable values will be less likely to be
inlined. But still, the point is: could nullable
values sometimes be inlined on the heap as opposed to
never being inlined.<br>
</span></font></span></font></span></div>
<div><span style="font-family:monospace"><font size="4"><span class="gmail_default" style="color:rgb(7,55,99)"><font size="4"><span class="gmail_default" style="color:rgb(7,55,99)"></span></font>
</span></font></span></div>
<div><span style="font-family:monospace"><font size="4"><br>
</font></span></div>
<div><span style="font-family:monospace"><font size="4"><br>
</font></span></div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div><span style="font-family:monospace"><font size="4"><span class="gmail_default" style="color:rgb(7,55,99)">
<span class="gmail_default" style="color:rgb(7,55,99)"></span>In
theory, we could construct the union type int|Null, but
this
(...) drags in all sorts of mismatches because union
types would then flow throughout the system.
</span><br>
</font></span></div>
</blockquote>
<div><span style="font-family:monospace"><font size="4"><br>
</font></span></div>
<div><span style="font-family:monospace"><font size="4"><br>
</font></span></div>
<div style="color:rgb(7,55,99)" class="gmail_default"><span style="font-family:monospace"></span></div>
<div style="color:rgb(7,55,99)" class="gmail_default"><span style="font-family:monospace"><font size="4">Is my
3-companion-types solution a real union type? Sure, I am
suggesting two sort-of-unions:</font></span></div>
<div style="color:rgb(7,55,99)" class="gmail_default"><span style="font-family:monospace"><font size="4"><br>
</font></span></div>
<div style="color:rgb(7,55,99)" class="gmail_default"><span style="font-family:monospace"><font size="4">
RefType|ValType - for non-nullable value-class variables<br>
</font></span></div>
<div style="color:rgb(7,55,99)" class="gmail_default"><span style="font-family:monospace"><font size="4">
RefType|ValType? - for nullable value-class variables<br>
</font></span></div>
<div style="color:rgb(7,55,99)" class="gmail_default"><span style="font-family:monospace"><font size="4"><br>
</font></span></div>
<div style="color:rgb(7,55,99)" class="gmail_default"><span style="font-family:monospace"><font size="4">However, to the
user, both types in each union represent the same exact
value-set.</font></span></div>
</blockquote>
<br>
My comments: <br>
<br>
<font size="4" face="monospace">Except the model proposed actually
had _more_ knobs than where we are now: just as many
declaration-site knobs (no identity, tearable, zeroable), and more
use-site knobs (atomic, nullable.) <br>
</font>
<p><font size="4" face="monospace">Reading between the lines, what I
think is going on here is: ".val is ugly, can we find a way to
spell it !, so we can pretend there aren't really two things."
<br>
</font></p>
<p><font size="4" face="monospace">And I totally get the desire to
do this! But I don't think these are the droids you are looking
for. The overwhelming lesson of Valhalla has been: every time
we try to associate something with nullity (identity,
reference-ness, flattening, atomicity, etc), it turns out to be
a mistake. <br>
</font></p>
<blockquote type="cite">
<div><span style="font-family:monospace"><font size="4"><br>
</font></span></div>
<span style="font-family:monospace"><font size="4"><span class="gmail_default" style="color:rgb(7,55,99)">Would it be
possible to have a value-class give rise to these 3
hidden/runtime-only companion-types <font size="4"><span class="gmail_default" style="color:rgb(7,55,99)"> on the
heap</span></font>:</span></font></span>
<div><span style="font-family:monospace"><font size="4"><span class="gmail_default" style="color:rgb(7,55,99)"><br>
</span></font></span></div>
<div><span style="font-family:monospace"><font size="4"><span class="gmail_default" style="color:rgb(7,55,99)">
RefType - reference to a value-instance or no-reference
(null)<br>
</span></font></span></div>
<div><span style="font-family:monospace"><font size="4"><span class="gmail_default" style="color:rgb(7,55,99)">
ValType - inlined [value-instance-fields]<br>
</span></font></span></div>
<div><span style="font-family:monospace"><font size="4"><span class="gmail_default" style="color:rgb(7,55,99)">
ValType? - inlined [nullability-boolean +
<font size="4"><span class="gmail_default" style="color:rgb(7,55,99)">value-instance-fields]</span></font></span></font></span></div>
</blockquote>
<br>
<font size="4"><font face="monospace">I think there are at least two
tails wagging this dog here -- the syntax tail (I want to say
?/!, not .ref/.val) and the performance tail. Note that the
RefType and ValType? in this breakdown are semantically
identical! The only difference is the assumed performance model
-- "reference vs inlined." But we *already* can do significant
flattening on the .ref types (calling convention and locals.)
If we could achieve the kind of inlining you want for ValType?
in the heap, we would just do it for RefType too, and we
wouldn't need a third thing. So this breakdown is just making
it needlessly more complicated for no benefit. <br>
<br>
</font></font>
</body>
</html>