----- Mail original ----- > De: "daniel smith" <[email protected]> > À: "Remi Forax" <[email protected]> > Cc: "valhalla-spec-experts" <[email protected]> > Envoyé: Vendredi 14 Juin 2019 18:56:40 > Objet: Re: Draft LW2 spec
>> On Jun 14, 2019, at 2:54 AM, Remi Forax <[email protected]> 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
