From forax at univ-mlv.fr Thu Dec 1 09:29:03 2022 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Thu, 1 Dec 2022 10:29:03 +0100 (CET) Subject: Null restricted type and JSpecify In-Reply-To: <26824341-F4F6-4FE4-8888-39C0F7CD1C2D@oracle.com> References: <1508664657.51644988.1669208620662.JavaMail.zimbra@u-pem.fr> <1991372969.56691342.1669828009619.JavaMail.zimbra@u-pem.fr> <26824341-F4F6-4FE4-8888-39C0F7CD1C2D@oracle.com> Message-ID: <1691183194.57088288.1669886943419.JavaMail.zimbra@u-pem.fr> ----- Original Message ----- > From: "John Rose" > To: "Remi Forax" > Cc: "valhalla-spec-experts" > Sent: Wednesday, November 30, 2022 7:21:24 PM > Subject: Re: Null restricted type and JSpecify > On 30 Nov 2022, at 9:06, forax at univ-mlv.fr wrote: > >> ----- Original Message ----- >>> From: "John Rose" >>> To: "Remi Forax" >>> Cc: "valhalla-spec-experts" >>> Sent: Wednesday, November 30, 2022 6:01:42 PM >>> Subject: Re: Null restricted type and JSpecify >> >>> Kevin & co won?t like this maybe, but I think this design and our Valhalla >>> design do not conflict, precisely because they make completely distinct sets of >>> assertions, and yet the assertions (taken together) are consistent. >>> >>> What we are talking about here is X! on non-type-vars. That means we are adding >>> a state EXPLICIT_MINUS_NULL, which (a) has an obvious relation to the other >>> states in JSpec., and (b) can have a semantic weight different from anything in >>> JSpec.; it can and should translate to a different Q-descriptor. > > Disclaimer! By the way, my use of X! doesn?t imply a particular bikeshed for > the syntax. JSpec. spells it @NonNull, one draft of Valhalla spells it .val > (as in Point.val), and ?everybody knows? what X! means, kind of. Except they > don?t: Different languages give very different meanings (sometimes in very > subtle details) to their emo-type syntaxes. There! > >> >> if it's L-descriptor in descriptors but Q-descriptor in TypeRestriction + >> bytecodes, yes ! >> >> I think being able to add a '!' if you have overlook one should be an option. > > As we discussed in the EG just now, this is a distinct proposal which should > be taken up independently of anything we do regarding JSpecify. > > At the VM level, we are planning to do (for generics) some sort of type > restrictions which are semantically enforces but DO NOT appear in the > descriptor; it is a side channel to the descriptor. So L-Point could > be a translation of Point.val (aka Point! but see above) instead of > Q-Point, as long as there is a type restriction lurking somewhere near > that specific occurrence of L-Point. > > Technically we could do this at some level. But I?d like to challenge > this proposal, by a counter-proposal that (I think) would first have > to hold water, in order to translate Point.val as L-Point+TR. That > counter proposal is, experimentally amend today?s Java translation > strategy so that every use the descriptor I (for int) in APIs is > changed to L-Integer plus a TR, so that (basically) int erases to > Integer, with a TR. Suppose some reasonable JVM support for TRs > of this form (just for primitive types, for now). Now, can you > implement the JLS? Should you do it this way? > > For bonus points (as you suggested in the meeting) see if you can > erase ALL TYPES to L-Object, with associated TRs. Does it work? > Would it be smart? > > If these experiments would go wrong somehow, I suggest, strongly, > that a similar voyage into erasure for Q-Point into L-Point+TR > would also go wrong, in similar ways. > > For starters, some overloaded functions would be broken in either > of those thought experiments. That should make us a little bit > scared to do that same thing for the new Q-types. I suspect there > are a number of ?gotchas? like this. We spent the first couple > of years on the Valhalla project enumerating such gotchas, for > various proposals. Generally speaking it has turned out that > erasing Q to L seems OK about 80% of the way through the details, > and then something jumps out and bites, related to details of the > JLS, or JVM optimizations, or binary compatibility, or all three > at the same time. > I wonder if you are making the problem harder than it is. Valhalla can be decomposed into 3 goals, 1) Provides value/primitive classes 2) Heal the rift between primitive classes and primitive types 3) Provides generics over value/primitive classes I believe that wanting all primitive classes (or worst all value classes) to behave/be potential primitive types is a kind of over-generalization. Let's summarize the difference between a primitive type and a primitive class - a primitive type has a special kind of descriptor, a special kind of opcodes (iload vs aload), special kind of arrays (anewarray vs newarray), etc - a primitive type has a special kind of runtime mirror (int.class, double.class, etc) - a primitive type has a special kind of ==, <, >, etc (float/double semantics (IEEE 754) is not compatible with Float/Double semantics) - a primitive type is always flattened Some of the differences are historical accidents but for me, the major difference between a primitive class and a primitive type is that flattening is *guaranteed* for a primitive type and the fact that it has its own descriptor and bytecodes is a direct consequence of that decision. So in term of translation strategy, wanting value/primitive classes to be translated in bytecode with the same properties for overloading, etc than primitive types should not be a goal. > ? John R?mi From daniel.smith at oracle.com Thu Dec 1 15:27:08 2022 From: daniel.smith at oracle.com (Dan Smith) Date: Thu, 1 Dec 2022 15:27:08 +0000 Subject: Null restricted type and JSpecify In-Reply-To: <1691183194.57088288.1669886943419.JavaMail.zimbra@u-pem.fr> References: <1508664657.51644988.1669208620662.JavaMail.zimbra@u-pem.fr> <1991372969.56691342.1669828009619.JavaMail.zimbra@u-pem.fr> <26824341-F4F6-4FE4-8888-39C0F7CD1C2D@oracle.com> <1691183194.57088288.1669886943419.JavaMail.zimbra@u-pem.fr> Message-ID: On Dec 1, 2022, at 1:29 AM, forax at univ-mlv.fr wrote: Let's summarize the difference between a primitive type and a primitive class - a primitive type has a special kind of descriptor, a special kind of opcodes (iload vs aload), special kind of arrays (anewarray vs newarray), etc - a primitive type has a special kind of runtime mirror (int.class, double.class, etc) - a primitive type has a special kind of ==, <, >, etc (float/double semantics (IEEE 754) is not compatible with Float/Double semantics) - a primitive type is always flattened Some of the differences are historical accidents but for me, the major difference between a primitive class and a primitive type is that flattening is *guaranteed* for a primitive type and the fact that it has its own descriptor and bytecodes is a direct consequence of that decision. So in term of translation strategy, wanting value/primitive classes to be translated in bytecode with the same properties for overloading, etc than primitive types should not be a goal. I could quibble with some of the details (e.g., what does it mean to be "guaranteed" to be flattened??JVMs are free to allocate doubles on heap if they really want to, I think), but I share the sentiment. Specifically: - However we've tried to squeeze the legacy primitives into our story, there are always seams. One way or another, they are going to be special. They should "fit" with the rest of the story, but it's perfectly fine for certain aspects of their treatment to be special-cased. I think it's useful to sometimes break away from a "what would 'int' do?" design approach, and instead focus on "how should the new feature work, on its own terms?"; then after that's resolved, come back and figure out how 'int' fits in. - There's a tension between making 'Point!' consistent with 'String!' and making it consistent with 'int'. Given the identical syntax and the previous point about 'int', I'm inclined to prioritize consistency with 'String!'. - At its core, 'Point!'/'Point' really *doesn't* convey the same physical/performance model as 'int'/'Integer'. That's deliberate?a benefit of the '!' approach is that it discourages programmers from thinking about physical characteristics, and instead focuses them on whether they want 'null' in their domain. - Specifically on overloading, I don't think there's a practical need, at the language level, for overloading 'm(Point)' with 'm(Point!)', and it even feels like an anti-feature. (E.g., if you're writing that code, you're probably doing something wrong.) Overloading of 'int' with 'Integer' makes sense because of the physical/performance model, and because of generics limitatations (e.g., implementing Predicate). Neither of those apply to 'Point!'. -------------- next part -------------- An HTML attachment was scrubbed... URL: From andvasp at gmail.com Sat Dec 3 14:39:47 2022 From: andvasp at gmail.com (Anderson Vasconcelos Pires) Date: Sat, 3 Dec 2022 11:39:47 -0300 Subject: EG meeting, 2022-11-16 In-Reply-To: References: Message-ID: Hi Dan and Experts! About the "new ideas about modeling flattening in the language", I've seen some emails but it is a little bit fuzzy what is going on. May inform us summarized what is being proposed? Thanks in advance! Anderson. On Tue, Nov 15, 2022 at 4:51 PM Dan Smith wrote: > EG Zoom meeting November 16 at 5pm UTC (9am PDT, 12pm EDT). > > We're back with some new ideas about modeling flattening in the language! > Brian has some slides to share, and hopefully that will prompt a good > discussion. Hope everyone can make it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.smith at oracle.com Tue Dec 13 20:06:32 2022 From: daniel.smith at oracle.com (Dan Smith) Date: Tue, 13 Dec 2022 20:06:32 +0000 Subject: EG meeting *canceled*, 2022-12-14 Message-ID: We've got an internal meeting conflict at Oracle, so will have to cancel this week's EG meeting. The next scheduled meeting time is during our winter break, so we'll skip that as well and get back together again on January 11. Happy holidays, everyone! From forax at univ-mlv.fr Wed Dec 14 08:48:31 2022 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 14 Dec 2022 09:48:31 +0100 (CET) Subject: EG meeting *canceled*, 2022-12-14 In-Reply-To: References: Message-ID: <958473958.66249518.1671007711083.JavaMail.zimbra@u-pem.fr> Happy holidays ! R?mi ----- Original Message ----- > From: "daniel smith" > To: "valhalla-spec-experts" > Sent: Tuesday, December 13, 2022 9:06:32 PM > Subject: EG meeting *canceled*, 2022-12-14 > We've got an internal meeting conflict at Oracle, so will have to cancel this > week's EG meeting. > > The next scheduled meeting time is during our winter break, so we'll skip that > as well and get back together again on January 11. > > Happy holidays, everyone!