<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">On May 15, 2018, at 1:05 AM, <a href="mailto:forax@univ-mlv.fr" class="">forax@univ-mlv.fr</a> wrote:<br class=""><div><blockquote type="cite" class=""><br class="Apple-interchange-newline"><div class=""><div class=""><div style="font-size: 12pt;" class=""><div data-marker="__QUOTED_TEXT__" class=""><blockquote style="border-left-width: 2px; border-left-style: solid; border-left-color: rgb(16, 16, 255); margin-left: 5px; padding-left: 5px; font-weight: normal; font-style: normal; text-decoration: none; font-size: 12pt;" class=""><div class=""><div class=""><br class=""><font face="arial, helvetica, sans-serif" class="">...</font></div><font face="Helvetica, Arial, sans-serif" class="">You must admit this use of supers to carry nullable values is possible,</font></div><div class="" style="font-family: Helvetica, Arial, sans-serif;">but you are saying (I think) that you don't agree that this is useful.</div></blockquote><div class="" style="font-family: arial, helvetica, sans-serif;"><br class=""></div><div class="" style="font-family: arial, helvetica, sans-serif;">We have already decided that j.l.Object is the super that can carry null, so yes, we do not need another one.<br data-mce-bogus="1" class=""></div></div></div></div></div></blockquote><div><br class=""></div>I see.  Yes, the clever ValueRef adds mainly static checking, because it can</div><div>carry a type parameter.  Other than that, it is just another Object.</div><div><br class=""></div><div>…We could also play this move:  An interface ValueRef<VT> could be defined</div><div>such that, at the JVM level, the JVM enforces that (x instanceof ValueRef)</div><div>if and only if (x.getClass().isValue()).  The JVM would simply enforce the</div><div>corresondence at class load time.   It's a play I'm keeping in my pocket,</div><div>which could add special runtime strength to a static typing story.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><div style="font-size: 12pt;" class=""><div data-marker="__QUOTED_TEXT__" class=""><div class="" style="font-family: arial, helvetica, sans-serif;">...</div><div class="" style="font-family: arial, helvetica, sans-serif;">In a sense, you're right, asking for nullability comes with a high cost, it's not flattenable (otherwise you can not store null), acmp => false (it's a value type at runtime) but you still have the fact that JITs that can spill a nullable value type in registers which is an important case. The idea is that even if a nullable value type escapes, the JIT doesn't have to keep it, it can spread it into its multiple components and gather it when it escapes.<br data-mce-bogus="1" class=""></div><div class="" style="font-family: arial, helvetica, sans-serif;"><br data-mce-bogus="1" class=""></div><div class="" style="font-family: arial, helvetica, sans-serif;">If you take a look to Optional or LocalDate, i'm not sure the need for flattening is that important, but being able to consider it has a value type inside an inlining blob (inside a function of the generated assembly) is important in term of performance when you do operation like map()/filter() or plus*()/minus*(). <br data-mce-bogus="1" class=""></div></div></div></div></div></blockquote><div><br class=""></div><div>This is an interesting tricky point.  I'm glad it's moot for 99.9% of value types,</div><div>which are the non-migrated ones.</div><div><br class=""></div><div>Dan's objections to non-nullable migrated arrays would be met, at very high</div><div>performance cost, by making arrays of these types nullable also.  What do</div><div>you think about flattening arrays of these specially marked VTs (that were</div><div>VBCs)?  If we *don't* flatten arrays of a particular VT, then we need a special</div><div>way to convey that decision to the JVM.</div><div><br class=""></div><div><div>(I wonder if Panama vector types would tolerate such a move:  We mainly</div><div>need in-loop optimizations, so nullability would be tolerable there, but having</div><div>them boxed in arrays would be a non-starter.)</div><div><br class=""></div></div><blockquote type="cite" class=""><div class=""><div class=""><div style="font-size: 12pt;" class=""><div data-marker="__QUOTED_TEXT__" class=""><blockquote style="font-family: Helvetica, Arial, sans-serif; border-left-width: 2px; border-left-style: solid; border-left-color: rgb(16, 16, 255); margin-left: 5px; padding-left: 5px; font-weight: normal; font-style: normal; text-decoration: none; font-size: 12pt;" class=""><div class=""><br class=""></div><div class="">0. leave it alone, it's a VBC</div><div class="">1. make it a proper value type, get flattening on recompile, and deal with the null hygiene fallout</div><div class="">0.1 make it a value type but mark it @VBC, no sync or acmp, no flattening either</div></blockquote><div class="" style="font-family: arial, helvetica, sans-serif;"><br class=""></div><div class="" style="font-family: arial, helvetica, sans-serif;">but it's nullable, the semantics is simple and mostly backward compatible (== does not work, use equals instead, do not synchronize on it) and no allocation cost where it can be important like in loops.</div><div class="" style="font-family: arial, helvetica, sans-serif;">in my opinion, yes, it's a trade off, but it's closer to 0.5 than 0.1.  <br data-mce-bogus="1" class=""></div></div></div></div></div></blockquote><div><br class=""></div><div>OK, I see how it is worth the experiment.  It's nice that (except for the</div><div>array question) it's purely in the translation strategy:  The existing proposed</div><div>ValueTypes attribute would (as you say) simply never mention such a</div><div>marked VT.</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div class=""><div style="font-size: 12pt;" class=""><div data-marker="__QUOTED_TEXT__" class=""><div class="" style="font-family: arial, helvetica, sans-serif;"><br data-mce-bogus="1" class=""></div><blockquote style="font-family: Helvetica, Arial, sans-serif; border-left-width: 2px; border-left-style: solid; border-left-color: rgb(16, 16, 255); margin-left: 5px; padding-left: 5px; font-weight: normal; font-style: normal; text-decoration: none; font-size: 12pt;" class=""><div class=""><br class=""></div><div class="">The use-site choices for VTs are:</div><div class=""><br class=""></div><div class="">0. what choice?  you didn't want that API point anyway</div><div class="">1. Object is the untyped workaround for all your nullable needs</div><div class="">1.2 clever ValueRef<VT> is your statically typed workaround for nullables</div></blockquote><div class="" style="font-family: arial, helvetica, sans-serif;"><br class=""></div><div class="" style="font-family: arial, helvetica, sans-serif;">at the cost of some oddities like what ValueRef<?> or ValueRef.class means.<br data-mce-bogus="1" class=""></div></div></div></div></div></blockquote><div><br class=""></div><div>See above:  It would mean "this is any value type".  Surely that's useful?</div><div>We already have reflective Class.isValue, and this would be the static type</div><div>for the same concept.  (You see I'm reluctant to kill this "darling"[1].)</div><div><br class=""></div><div>[1] <a href="https://en.wiktionary.org/wiki/kill_one%27s_darlings" class="">https://en.wiktionary.org/wiki/kill_one%27s_darlings</a></div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div style="font-size: 12pt;" class=""><div data-marker="__QUOTED_TEXT__" class=""><blockquote style="font-family: Helvetica, Arial, sans-serif; border-left-width: 2px; border-left-style: solid; border-left-color: rgb(16, 16, 255); margin-left: 5px; padding-left: 5px; font-weight: normal; font-style: normal; text-decoration: none; font-size: 12pt;" class=""><div class=""><br class="">2. Q-world:  ad hoc variations everywhere between L-VT and Q-VT (cost += 1e6)</div><div class="">3. some sugar like VT.BOX or an annotation for one of the previous</div></blockquote><div class="" style="font-family: arial, helvetica, sans-serif;"><br class=""></div><div class="" style="font-family: arial, helvetica, sans-serif;">and in all cases, each use-site choice means that people will have to annotate their code to make it works like it were working before with respect of null, so it's not really a practical option because Optional is so widespread in the code that all the codes that contains Optional will never be rewritten. <br data-mce-bogus="1" class=""></div></div></div></div></blockquote><br class=""></div><div>We're in a tug-of-war here, between the goal of migratability and</div><div>the prime goal of value types (mainly flattenability, of all variables).</div><div>One side says "I need to flatten your variable *here*" and the other</div><div>side says, "nope, not backward compatible".  Maybe we're proving</div><div>that migration is not really possible.  We are certainly proving that</div><div>migration is tricky and requires compromising various kinds of</div><div>correctness (relative to the pre-migrated semantics).</div><div><br class=""></div><div>Ultimately, we must flatten values, except perhaps for a negligible</div><div>clearly marked fraction of "compromised values" which dragged</div><div>themselves away from VBC-hood, but incompletely.  Ultimately</div><div>we must tell the migrators to migrate with semantic changes,</div><div>or not migrate.   To paraphrase Yoda, "either do or do not,</div><div>but about it don't cry."</div><div><br class=""></div><div>— John</div></body></html>