Draft LW2 spec

[forax at univ-mlv.fr]

----- Mail original -----
> De: "daniel smith" <daniel.smith at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "valhalla-spec-experts" <valhalla-spec-experts at openjdk.java.net>
> Envoyé: Vendredi 14 Juin 2019 18:56:40
> Objet: Re: Draft LW2 spec

>> On Jun 14, 2019, at 2:54 AM, Remi Forax <forax at univ-mlv.fr> wrote:
>> 
>> Hi Daniel,
>> 
>> section 4.1: in the table 4.1-A,
>> 13/57/45..57 is missing given you talk about later in this section.
> 
> That's not a change this feature is responsible for, but you're right that it
> needs to be changed.
> 
> We have this awkward bootstrapping problem, where the document as it's being
> developed is built on top of 12, but eventually needs to be rebased to 13. Now
> that JVMS 13 is final, I could take a stab at rebasing everything.

it's a side effect of the new release cadence and 14 is around the corner ...

> 
>> section 4.3.2:
>>  I don't think that using null as a diferentiator (Nullable/NonNullable) is a
>>  good idea.
>>  Yes, an inline type is not nullable, but it's also flattenable, loaded early,
>>  not circular, etc. This introduce a false dichotomy which we have already spent
>>  too much time. I don't remember the exact words that John is using, but it was
>>  making more sense too me.
>>   Perhaps only renaming NullFreeClassType to InlineClassType is enough ?
> 
> I'll think more about this terminology. "Inline class type" is not sufficient,
> because QVal; and LVal; are *both* inline class types.

is it not better to try to separate the type notion from the class notion ?
L and Q are type, L is an identity type, Q an inline type and at runtime an inline class can be typed as an identity type (L) or an inline type (Q).

> 
>> section 4.10.1.2:
>>   the bottom right of the schema is wrong because a reference type can be a
>>   nullable type or an inline type which is not nullable
>>   I propose
>>     
>>             reference type
>>               /        \
>>             /           \
>>    nullable type     inline class
>>          |
>>          |
>>         null
> 
> Yep. I was hoping I could get away with some hand-waving. Guess not. :-)
> 
> The struggle here is that "reference type hierarchy" is meant to be a black box.
> I guess one way to make this work is to put 'null' in the box and remove it
> from the diagram. Another way is to break open the box, as you've done, but
> note that then you've got informal descriptions of types in a diagram that
> otherwise talks explicitly about specific types, and it's a lost cause trying
> to appropriately model the relationships between those informal descriptions
> (e.g., each inline class type is a subtype of some nullable types).

Rémi