<div dir="ltr"><div class="gmail_default" style="font-family:verdana,sans-serif;color:#073763">
<div style="color:rgb(7,55,99)" class="gmail_default"><font size="4"><span style="font-family:monospace">Hello Brian,</span></font></div><div style="color:rgb(7,55,99)" class="gmail_default"><font size="4"><span style="font-family:monospace"><br></span></font></div><div style="color:rgb(7,55,99)" class="gmail_default"><font size="4"><span style="font-family:monospace"><br></span></font></div><div style="color:rgb(7,55,99)" class="gmail_default"><font size="4"><span style="font-family:monospace">Thank you very much for your replies.</span></font></div><div style="color:rgb(7,55,99)" class="gmail_default"><font size="4"><span style="font-family:monospace">I would like to start by saying that it's been a pleasure to listen and read what you have been saying in these past few years on all kinds of matters related to computer science. It's actually my appreciation of your work, your clarity of thinking and your easy-to-understand explanations that has led me here, trying to get some insight into the new and fascinating things you are working on. Needless to say that, relative to project Valhalla, practically all I know is what I have learned from you. So I am well aware that if I am not agreeing or understanding something you are saying I know that most likely you are right and I am wrong.<br></span></font></div><div style="color:rgb(7,55,99)" class="gmail_default"><font size="4"><span style="font-family:monospace">Having said this, I hope you continue to find this discussion worth having. My feedback to your comments is below.<br></span></font></div><div style="color:rgb(7,55,99)" class="gmail_default"><font size="4"><span style="font-family:monospace"><br></span></font></div><div style="color:rgb(7,55,99)" class="gmail_default"><font size="4"><span style="font-family:monospace"><br></span></font></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail_default" style="color:rgb(7,55,99)"><font size="4"><span style="font-family:monospace"><span style="color:rgb(0,0,0)">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.) </span> </span></font></div></blockquote><div><font size="4"><span style="font-family:monospace"><span class="gmail_default" style="color:rgb(7,55,99)"></span><br></span></font></div><div><font size="4"><span style="font-family:monospace"><br></span></font></div><div style="color:rgb(7,55,99)" class="gmail_default"><font size="4"><span style="font-family:monospace">Yes, I really haven't said much on this: The nullable-knob is "bang" and the atomic-knob is basically "volatile". I gave it a different name because reading through (<span style="color:rgb(7,55,99)">§</span>17.4.5.), it looks like "volatile" introduces "Happens-before Order" which I understand does more than we need, which is: just undo the effects of the tearable-knob. But maybe I am misinterpreting this and the "volatile" we already have is just the atomic-knob I was looking for.<br></span></font></div><div style="color:rgb(7,55,99)" class="gmail_default"><font size="4"><span style="font-family:monospace"><br></span></font></div><div style="color:rgb(7,55,99)" class="gmail_default"><font size="4"><span style="font-family:monospace"><br></span></font></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail_default"><font size="4"><span style="font-family:monospace"><span style="color:rgb(0,0,0)">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."</span></span></font></div></blockquote><div><font size="4"><span style="font-family:monospace"><br></span></font></div><div><font size="4"><span style="font-family:monospace"><br></span></font></div><div style="color:rgb(7,55,99)" class="gmail_default"><font size="4"><span style="font-family:monospace">Maybe you are correctly reading between my mental lines, but I was actually trying to make a deliberate effort to not care about syntax (which is a valuable lesson I learned from you). That is why I have been calling everything "such-and-such-knob".<br></span></font></div><div style="color:rgb(7,55,99)" class="gmail_default"><font size="4"><span style="font-family:monospace">But in fact, what you are saying here is precisely my point. We have two complected things masquerading as one:</span></font></div><div style="color:rgb(7,55,99)" class="gmail_default"><font size="4"><span style="font-family:monospace"><br></span></font></div><div style="color:rgb(7,55,99)" class="gmail_default"><font size="4"><span style="font-family:monospace"> 1 - encoding-mode: reference - (nullable)<br></span></font></div><div style="color:rgb(7,55,99)" class="gmail_default"><font size="4"><span style="font-family:monospace"> 2 - encoding-mode: inline - (non-nullable)</span></font></div><div style="color:rgb(7,55,99)" class="gmail_default"><font size="4"><span style="font-family:monospace"><br></span></font></div><div style="color:rgb(7,55,99)" class="gmail_default"><font size="4"><span style="font-family:monospace">Encoding-mode and nullability are completely orthogonal concepts and I think we have them complected simply due to convenience:</span></font></div><div style="color:rgb(7,55,99)" class="gmail_default"><font size="4"><span style="font-family:monospace"><br></span></font></div><div style="color:rgb(7,55,99)" class="gmail_default"><font size="4"><span style="font-family:monospace"> 1 - It's very easy/convenient to represent null with reference-encoding<br></span></font></div><div style="color:rgb(7,55,99)" class="gmail_default"><font size="4"><span style="font-family:monospace"> 2 - It's cumbersome/inconvenient to represent null with inline-encoding</span></font></div><div style="color:rgb(7,55,99)" class="gmail_default"><font size="4"><span style="font-family:monospace"><br></span></font></div><div style="color:rgb(7,55,99)" class="gmail_default"><font size="4"><span style="font-family:monospace">Also, when you say that unknowingly I am thinking: "<span style="color:rgb(0,0,0)">.val is ugly, can we find a way to spell it !</span>" and "<span style="color:rgb(0,0,0)">I want to say
?/!, not .ref/.val</span>", <span style="color:rgb(7,55,99)">w<span class="gmail_default"></span>hat I think I am thinking is:<span class="gmail_default"></span></span></span></font></div><div style="color:rgb(7,55,99)" class="gmail_default"><font size="4"><span style="font-family:monospace"><span style="color:rgb(7,55,99)"><span class="gmail_default"></span>"Runtime, this variable does/does-not need null in its value-set. Now you decide what is best: ValType or RefType?"</span></span></font></div><div style="color:rgb(7,55,99)" class="gmail_default"><font size="4"><span style="font-family:monospace"><br></span></font></div><div style="color:rgb(7,55,99)" class="gmail_default"><font size="4"><span style="font-family:monospace"><br></span></font></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"><font size="4"><span style="font-family:monospace">T<span style="color:rgb(0,0,0)">he 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.</span></span></font></div></blockquote><div><font size="4"><span style="font-family:monospace"><br></span></font></div><div><font size="4"><span style="font-family:monospace"><br></span></font></div><div style="color:rgb(7,55,99)" class="gmail_default"><font size="4"><span style="font-family:monospace">Well, that is exactly my point: let's take the last step and decouple nullity from everything, because right now, it still is associated with reference-ness and flattening.</span></font></div><div style="color:rgb(7,55,99)" class="gmail_default"><font size="4"><span style="font-family:monospace">You have written about this conflict with nullability a few times now, and that was actually a good part of the inspiration/reason that moved me to write this.</span></font></div><div style="color:rgb(7,55,99)" class="gmail_default"><font size="4"><span style="font-family:monospace"><br></span></font></div><div style="color:rgb(7,55,99)" class="gmail_default"><font size="4"><span style="font-family:monospace"><br></span></font></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail_default"><font size="4"><span style="font-family:monospace"><span style="color:rgb(0,0,0)">Note that the
RefType and ValType? in this breakdown are semantically
identical! The only difference is the assumed performance model
-- "reference vs inlined."</span></span></font></div></blockquote><div><font size="4"><span style="font-family:monospace"><br></span></font></div><div><font size="4"><span style="font-family:monospace"> </span></font></div><div style="color:rgb(7,55,99)" class="gmail_default"><font size="4"><span style="font-family:monospace">Yes, the point is to be able to modify the "performance model" without affecting semantics. The user does not care about the encoding-mode, the user only cares about:</span></font></div><div style="color:rgb(7,55,99)" class="gmail_default"><font size="4"><span style="font-family:monospace"><br></span></font></div><div style="color:rgb(7,55,99)" class="gmail_default"><font size="4"><span style="font-family:monospace"> - identity<br></span></font></div><div style="color:rgb(7,55,99)" class="gmail_default"><font size="4"><span style="font-family:monospace"> - variable nullability</span></font></div><div style="color:rgb(7,55,99)" class="gmail_default"><font size="4"><span style="font-family:monospace"> - atomicity/tearing</span></font></div><div style="color:rgb(7,55,99)" class="gmail_default"><font size="4"><span style="font-family:monospace"> - zero-value hazards<br></span></font></div><div style="color:rgb(7,55,99)" class="gmail_default"><font size="4"><span style="font-family:monospace"> - performance/footprint</span></font></div><div style="color:rgb(7,55,99)" class="gmail_default"><font size="4"><span style="font-family:monospace"><br></span></font></div><div style="color:rgb(7,55,99)" class="gmail_default"><font size="4"><span style="font-family:monospace">Ref-ness and flatness are just means to an end: delivering the highest performance-model possible given the information provided by the user (via the knobs). That is why I think .ref and .val should not be part of the user-model but rather a runtime implementation detail.<br></span></font></div><div style="color:rgb(7,55,99)" class="gmail_default"><font size="4"><span style="font-family:monospace"><br></span></font></div><div style="color:rgb(7,55,99)" class="gmail_default"><font size="4"><span style="font-family:monospace"><br></span></font></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"><font size="4"><span style="font-family:monospace"><span style="color:rgb(0,0,0)">But we *already* can do significant
flattening on the .ref types (calling convention and locals.)</span><br></span></font></div></blockquote><div style="color:rgb(7,55,99)" class="gmail_default"><font size="4"><span style="font-family:monospace"><br></span></font></div><div style="color:rgb(7,55,99)" class="gmail_default"><font size="4"><span style="font-family:monospace"><br></span></font></div><div style="color:rgb(7,55,99)" class="gmail_default"><font size="4"><span style="font-family:monospace">Actually, these very words were what led me to think: "Brian says we can have nullable-inlined-values in non-shared-variables via some kind of nullable-channel. Why not extend this trick to shared-variables as well?".<br></span></font></div><div style="color:rgb(7,55,99)" class="gmail_default"><font size="4"><span style="font-family:monospace"></span></font></div><div style="color:rgb(7,55,99)" class="gmail_default"><font size="4"><span style="font-family:monospace"><br></span></font></div><div style="color:rgb(7,55,99)" class="gmail_default"><font size="4"><span style="font-family:monospace"><br></span></font></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail_default"><font size="4"><span style="font-family:monospace"><span style="color:rgb(0,0,0)">If we could achieve the kind of inlining you want for ValType?
in the heap, we would just do it for RefType too, ...</span></span></font></div></blockquote><div><font size="4"><span style="font-family:monospace"><br></span></font></div><div><font size="4"><span style="font-family:monospace"><br></span></font></div><div style="color:rgb(7,55,99)" class="gmail_default"><font size="4"><span style="font-family:monospace">Here, I am not sure I understand. I was under the impression that inlining and RefType are opposite: A RefType is reference-encoded and a ValType is inline-encoded.</span></font></div><div style="color:rgb(7,55,99)" class="gmail_default"><font size="4"><span style="font-family:monospace">From what you are saying here, it looks like the definitions are simply:</span></font></div><div style="color:rgb(7,55,99)" class="gmail_default"><font size="4"><span style="font-family:monospace"><br></span></font></div><div style="color:rgb(7,55,99)" class="gmail_default"><font size="4"><span style="font-family:monospace"> RefType: null | value-instances (regardless of encoding-mode)<br></span></font></div><div style="color:rgb(7,55,99)" class="gmail_default"><font size="4"><span style="font-family:monospace"> ValType: value-instances (regardless of encoding-mode)</span></font></div><div style="color:rgb(7,55,99)" class="gmail_default"><font size="4"><span style="font-family:monospace"><br></span></font></div><div style="color:rgb(7,55,99)" class="gmail_default"><font size="4"><span style="font-family:monospace">Which makes sense as types are about value-sets and not about encodings. If that is what you mean, then ValType? is exactly the same as RefType (as you say) and my point translates to: let's inline RefTypes on the heap (<span style="color:rgb(7,55,99)">§</span>17.4.1. shared-variables).<br></span></font></div><div style="color:rgb(7,55,99)" class="gmail_default"><font size="4"><span style="font-family:monospace">However, from what I have been reading in the mailing list, it appears that the actual definitions are:</span></font></div><div style="color:rgb(7,55,99)" class="gmail_default"><font size="4"><span style="font-family:monospace"><br></span></font></div><div style="color:rgb(7,55,99)" class="gmail_default"><div style="color:rgb(7,55,99)" class="gmail_default"><font size="4"><span style="font-family:monospace"> RefType: null | value-instances + (atomicity, null-default, higher-footprint, higher-latency)<br></span></font></div><div style="color:rgb(7,55,99)" class="gmail_default"><font size="4"><span style="font-family:monospace"> ValType: value-instances + (tearing, zero-default, lower-footprint, lower-latency)</span></font></div><div style="color:rgb(7,55,99)" class="gmail_default"><font size="4"><span style="font-family:monospace"><br></span></font></div><div style="color:rgb(7,55,99)" class="gmail_default"><font size="4"><span style="font-family:monospace">Which is also reasonable: types are about value-sets and also any other associated semantic or runtime characteristics. But in that case I don't understand your statement above, since under this definition, RefType and ValType are tightly coupled with the encoding-mode:<br></span></font></div><div style="color:rgb(7,55,99)" class="gmail_default"><font size="4"><span style="font-family:monospace"><br></span></font></div><div style="color:rgb(7,55,99)" class="gmail_default"><div style="color:rgb(7,55,99)" class="gmail_default"><font size="4"><span style="font-family:monospace"> RefType: null | value-instances + (reference-encoding)<br></span></font></div><div style="color:rgb(7,55,99)" class="gmail_default"><font size="4"><span style="font-family:monospace"> ValType: value-instances + (inline-encoding)</span></font></div><div style="color:rgb(7,55,99)" class="gmail_default"><font size="4"><span style="font-family:monospace"><br></span></font></div><div style="color:rgb(7,55,99)" class="gmail_default"><font size="4"><span style="font-family:monospace">Hence my proposed 3rd type:</span></font></div><div style="color:rgb(7,55,99)" class="gmail_default"><font size="4"><span style="font-family:monospace"><br></span></font></div><div style="color:rgb(7,55,99)" class="gmail_default"><font size="4"><span style="font-family:monospace"> ValType?: null | value-instances + (inline-encoding)</span></font></div><div style="color:rgb(7,55,99)" class="gmail_default"><font size="4"><span style="font-family:monospace"><br></span></font></div><div style="color:rgb(7,55,99)" class="gmail_default"><font size="4"><span style="font-family:monospace"><br></span></font></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"><font size="4"><span style="font-family:monospace">
<span style="color:rgb(0,0,0)">I think there are at least two
tails wagging this dog here -- the syntax tail (...) and the performance tail. </span>
</span></font></div></blockquote><div style="color:rgb(7,55,99)" class="gmail_default"><font size="4"><span style="font-family:monospace"><br></span></font></div><div style="color:rgb(7,55,99)" class="gmail_default"><font size="4"><span style="font-family:monospace"><br></span></font></div><div style="color:rgb(7,55,99)" class="gmail_default"><font size="4"><span style="font-family:monospace">
Here I must concede, I think I have been falling to the performance siren. I have been focusing on the ValType? and I have named this thread "nullable-inlined-values" when the most fundamental concept in my proposal is "Decomplecting nullability from encoding-mode" or maybe "Trading .val/.ref for nullable types".</span></font></div><div style="color:rgb(7,55,99)" class="gmail_default"><font size="4"><span style="font-family:monospace">Even if on nullable value-class shared-variables
we cannot have inline-encoding (as you say), we still get:</span></font></div><div style="color:rgb(7,55,99)" class="gmail_default"><font size="4"><span style="font-family:monospace"><br></span></font></div><div style="color:rgb(7,55,99)" class="gmail_default"><font size="4"><span style="font-family:monospace"> - no more .val/.ref on the user-model<br></span></font></div><div style="color:rgb(7,55,99)" class="gmail_default"><font size="4"><span style="font-family:monospace"> - choice of .ref/.val is left for the runtime<br></span></font></div><div style="color:rgb(7,55,99)" class="gmail_default"><font size="4"><span style="font-family:monospace"> - the same performance-model as the currently proposed model</span></font></div><div style="color:rgb(7,55,99)" class="gmail_default"><font size="4"><span style="font-family:monospace"> - nullable types on the user-model<br></span></font></div><div style="color:rgb(7,55,99)" class="gmail_default"><font size="4"><span style="font-family:monospace"><br></span></font></div><div style="color:rgb(7,55,99)" class="gmail_default"><font size="4"><span style="font-family:monospace"><br></span></font></div><div style="color:rgb(7,55,99)" class="gmail_default"><font size="4"><span style="font-family:monospace">João Mendonça<br></span></font></div><font size="4"><span style="font-family:monospace"></span></font></div><font size="4"><span style="font-family:monospace"></span></font></div><div style="color:rgb(7,55,99)" class="gmail_default"><font size="4"><span style="font-family:monospace"><br></span></font></div><div style="color:rgb(7,55,99)" class="gmail_default"><font size="4"><span style="font-family:monospace"><br></span></font></div>
</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 1 Jul 2022 at 12:02, Brian Goetz <<a href="mailto:brian.goetz@oracle.com" target="_blank">brian.goetz@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<br>
<font size="4"><font face="monospace"></font></font>
<blockquote type="cite"><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>
</div>
</blockquote></div>