value type hygiene

[John Rose]

On May 14, 2018, at 11:12 PM, forax at univ-mlv.fr wrote:
> 
> 
> 
> De: "John Rose" <john.r.rose at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "Brian Goetz" <brian.goetz at oracle.com>, "valhalla-spec-experts" <valhalla-spec-experts at openjdk.java.net>
> Envoyé: Mardi 15 Mai 2018 01:53:31
> Objet: Re: value type hygiene
> On May 14, 2018, at 4:13 PM, Remi Forax <forax at univ-mlv.fr <mailto:forax at univ-mlv.fr>> wrote:
> 
> I think i prefer a declaration site annotation like @ValueBasedClass to a use site annotation ValueRef<V>.

D'oh.  You said declaration site and you really meant it, at the declaration
of the value class itself?  I was responding as if you were proposing an
use-site annotation, where a method is declared that uses a VT but
wants to make that occurrence of the VT nullable.  So, some of my
reply was non-responsive; sorry.
> 
> In case it's not clear what I am proposing, I am not weighing in on language
> notations, but rather on VM structures in the context of the L-world experiment:
> 
>  - The L-world JVM should *not* be asked to invent two new runtime types for every VT.
>  - Nullable references to value types in new code should be expressed using reference types.
>  - In bytecodes, such nullable references can be Object or a new VT-specific interface or a mix of both.
> 
> I agree with your first 2 items but not the last one, a nullable reference should a L reference which is not listed in the attribute ValueTypes.

You must admit this use of supers to carry nullable values is possible,
but you are saying (I think) that you don't agree that this is useful.

> So to be clear, what i'm proposing is to have a way at source level to say it's a value type at runtime but it behave like a reference type,
> so a class which is tagged with the value type bit and that the compiler doesn't list in the attribute ValueTypes.

What would be the benefit of such a value type?  If it is nullable
everywhere, conversely it is flattenable nowhere.  That seems
like it's giving up a fair chunk of valuable value-ness.  The VT
itself would resist identity checks (acmp => false).  Would the
arrays be flattenable or not?  Seems to me that if a VT author
uses such a big hammer to ask for nullability, the arrays also
should allow null, hence be non-flattenable.  I don't see much
payoff from this user model.

> 
> 
> In source code, I really don't care how nullability is expressed:  annotation?
> keyword?  punctuation?  Java 5 generic?  etc.
> 
> In my opinion, it has to be a declaration site thing not a use site thing but as you said, i do not mind if it's an annotation or a keyword. But it should not be an erased generics since it's a use site 'annotation'.
> That why i said i prefer an annotation at declaration site like @ValueBased.
> ...
> I was not clear in my previous mail, i was proposing a declaration site mechanism like the annotation, not to use that annotation at runtime. 

Got it now; see above.

> ... it will be used for a handful class in the source code, it uses the attribute ValueTypes, for the VM side it's not another mechanism, it's the same mechanism but we let the end user to choose which kind of compatibility he wants. 

Changing a VBC to a VT, and then putting @VBC on it, is like ten steps
forward and nine steps back, if I'm correctly understanding the implications
about flattening.

So for def-site choices we have:

0. leave it alone, it's a VBC
1. make it a proper value type, get flattening on recompile, and deal with the null hygiene fallout
0.1 make it a value type but mark it @VBC, no sync or acmp, no flattening either

The use-site choices for VTs are:

0. what choice?  you didn't want that API point anyway
1. Object is the untyped workaround for all your nullable needs
1.2 clever ValueRef<VT> is your statically typed workaround for nullables
2. Q-world:  ad hoc variations everywhere between L-VT and Q-VT (cost += 1e6)
3. some sugar like VT.BOX or an annotation for one of the previous

— John