From forax at univ-mlv.fr Fri Sep 3 13:41:52 2021 From: forax at univ-mlv.fr (Remi Forax) Date: Fri, 3 Sep 2021 15:41:52 +0200 (CEST) Subject: JEP 406 Message-ID: <729759941.2862556.1630676512695.JavaMail.zimbra@u-pem.fr> While i was re-reding the JEP, something struck me as odd, in the method typeTester, in case of the enum Color, the method values() is called on an instance of the enum but this method is static, the code should be case Color c -> System.out.println("Color with " + Color.values().length + " values"); From forax at univ-mlv.fr Fri Sep 3 14:00:20 2021 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Fri, 3 Sep 2021 16:00:20 +0200 (CEST) Subject: Dominance in pattern matching for switch: Spec and Javac inconsistency In-Reply-To: <3A25E658-CA11-49B7-AD72-AA556098C2E5@selskabet.org> References: <1942616823.2516329.1630654194683.JavaMail.zimbra@u-pem.fr> <3A25E658-CA11-49B7-AD72-AA556098C2E5@selskabet.org> Message-ID: <1349000086.2878006.1630677620733.JavaMail.zimbra@u-pem.fr> > From: "Jesper Steen M?ller" > To: "Remi Forax" , "Ilyas Selimov" > > Cc: "compiler-dev" > Sent: Vendredi 3 Septembre 2021 10:30:58 > Subject: Re: Dominance in pattern matching for switch: Spec and Javac > inconsistency > Hi Hi, moved to spec-expert because there is an open question at the end, > If I understand correctly, a guarded switch label effectively can't dominate any > other labels, since the spec doesn't go into trying to statically analyze > whether or not the guard could ever be false. > I guess the spec could mention that (but it would be a comment, since it follows > from the other rules). A guarded switch pattern can not dominate any other guarded switch pattern that have the same type pattern prefix, e.g. case Integer i && foo(i) vs case Integer i && bar(i) but a guarded switch dominates it's prefix, e.eg case Integer i && foo(i) dominates case Integer. But there is no rule between a guarded pattern like case Integer i && foo(i) and case 1, so they can appear in any order. We may want to revisit that because from my own experience, it's not rare to add/remove guards to a pattern during the development, so forcing case 1 to dominate case Integer i && foo(i) means that you do not have to re-organize the case when you remove the guard. But I don't know if it's a good idea or not ? > -Jesper R?mi >> On 3 Sep 2021, at 09.29, Remi Forax < [ mailto:forax at univ-mlv.fr | >> forax at univ-mlv.fr ] > wrote: >>> From: "Ilyas Selimov" < [ mailto:ilyas.selimov at jetbrains.com | >>> ilyas.selimov at jetbrains.com ] > >>> To: "compiler-dev" < [ mailto:compiler-dev at openjdk.java.net | >>> compiler-dev at openjdk.java.net ] > >>> Sent: Vendredi 3 Septembre 2021 07:27:42 >>> Subject: Dominance in pattern matching for switch: Spec and Javac inconsistency >>> Hello! >>> The next code compiles correctly, but it seems to contradict the dominance >>> rules: >>> void test(Integer i) { >>> switch (i) { >>> case Integer in && in != null: >>> break; >>> case 1: >>> break; >>> case default: >>> break; >>> } >>> } >>>> A switch label that has a pattern case label element p dominates another switch >>>> label that has a constant case label element c if either of the following is >>> > true: >>>> - the type of c is a primitive type and its wrapper class (5.1.7) is a subtype >>> > of the erasure of the type of p. >>> Maybe the type of p should also be total for the type of selector expression >>> like in the rules for pattern-over-null dominance? >> For me, the problem comes from the guard, if you write the same code without the >> guard, the compiler correctly emits an error >> void test(Integer i) { >> switch (i) { >> case Integer in: >> break; >> case 1: >> break; >> case default: >> break; >> } >> } >> for me, this rule should apply even if p is a guard, the type of p when p is a >> guard is the type of the type part (the left part) of a guard. >> So it's more a bug in the implementation than a spec issue. >> But given that Eclipse has the same issue, the spec should be clarified. >>> Thanks, >>> Ilyas >> regards, >> R?mi From brian.goetz at oracle.com Fri Sep 3 20:03:42 2021 From: brian.goetz at oracle.com (Brian Goetz) Date: Fri, 3 Sep 2021 16:03:42 -0400 Subject: JEP 406 In-Reply-To: <729759941.2862556.1630676512695.JavaMail.zimbra@u-pem.fr> References: <729759941.2862556.1630676512695.JavaMail.zimbra@u-pem.fr> Message-ID: Fixed. On 9/3/2021 9:41 AM, Remi Forax wrote: > While i was re-reding the JEP, something struck me as odd, > in the method typeTester, in case of the enum Color, the method values() is called on an instance of the enum but this method is static, > the code should be > case Color c -> System.out.println("Color with " + Color.values().length + " values"); > From brian.goetz at oracle.com Fri Sep 3 20:07:57 2021 From: brian.goetz at oracle.com (Brian Goetz) Date: Fri, 3 Sep 2021 16:07:57 -0400 Subject: Dominance in pattern matching for switch: Spec and Javac inconsistency In-Reply-To: <1349000086.2878006.1630677620733.JavaMail.zimbra@u-pem.fr> References: <1942616823.2516329.1630654194683.JavaMail.zimbra@u-pem.fr> <3A25E658-CA11-49B7-AD72-AA556098C2E5@selskabet.org> <1349000086.2878006.1630677620733.JavaMail.zimbra@u-pem.fr> Message-ID: > > If I understand correctly, a guarded switch label effectively > can't dominate any other labels, since the spec doesn't go into > trying to statically analyze whether or not the guard could ever > be false. > I guess the spec could mention that (but it would be a comment, > since it follows from the other rules). > > > A guarded switch pattern can not dominate any other guarded switch > pattern that have the same type pattern prefix, > e.g. > ? case Integer i && foo(i) > vs > ? case Integer i && bar(i) > > but a guarded switch dominates it's prefix, > e.eg > ? case Integer i && foo(i) dominates case Integer. You've got that backwards; `Integer i` dominates `Integer i && g` for all g. > But there is no rule between a guarded pattern like case Integer i && > foo(i) and case 1, so they can appear in any order. Correct, a type pattern `T` should dominate any constant case labels of type T, but you are right, thsi does not seem to work properly. Also doesn't work with 17ea: jshell> int x = 3; switch (x) { case Integer i:} x ==> 3 |? Error: |? the switch statement does not cover all possible input values |?? switch (x) { case Integer i:} |?? ^---------------------------^ From forax at univ-mlv.fr Sat Sep 4 09:14:20 2021 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Sat, 4 Sep 2021 11:14:20 +0200 (CEST) Subject: JEP 406 In-Reply-To: References: <729759941.2862556.1630676512695.JavaMail.zimbra@u-pem.fr> Message-ID: <665269252.3059483.1630746860218.JavaMail.zimbra@u-pem.fr> Thanks, R?mi > From: "Brian Goetz" > To: "Remi Forax" , "amber-spec-experts" > > Sent: Vendredi 3 Septembre 2021 22:03:42 > Subject: Re: JEP 406 > Fixed. > On 9/3/2021 9:41 AM, Remi Forax wrote: >> While i was re-reding the JEP, something struck me as odd, >> in the method typeTester, in case of the enum Color, the method values() is >> called on an instance of the enum but this method is static, >> the code should be >> case Color c -> System.out.println("Color with " + Color.values().length + " >> values"); From forax at univ-mlv.fr Sat Sep 4 09:25:57 2021 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Sat, 4 Sep 2021 11:25:57 +0200 (CEST) Subject: Dominance in pattern matching for switch: Spec and Javac inconsistency In-Reply-To: References: <1942616823.2516329.1630654194683.JavaMail.zimbra@u-pem.fr> <3A25E658-CA11-49B7-AD72-AA556098C2E5@selskabet.org> <1349000086.2878006.1630677620733.JavaMail.zimbra@u-pem.fr> Message-ID: <1711061040.3061251.1630747557620.JavaMail.zimbra@u-pem.fr> > From: "Brian Goetz" > To: "Remi Forax" , "Jesper Steen M?ller" > > Cc: "Ilyas Selimov" , "amber-spec-experts" > > Sent: Vendredi 3 Septembre 2021 22:07:57 > Subject: Re: Dominance in pattern matching for switch: Spec and Javac > inconsistency >>> If I understand correctly, a guarded switch label effectively can't dominate any >>> other labels, since the spec doesn't go into trying to statically analyze >>> whether or not the guard could ever be false. >>> I guess the spec could mention that (but it would be a comment, since it follows >>> from the other rules). >> A guarded switch pattern can not dominate any other guarded switch pattern that >> have the same type pattern prefix, >> e.g. >> case Integer i && foo(i) >> vs >> case Integer i && bar(i) >> but a guarded switch dominates it's prefix, >> e.eg >> case Integer i && foo(i) dominates case Integer. > You've got that backwards; `Integer i` dominates `Integer i && g` for all g. yes ! >> But there is no rule between a guarded pattern like case Integer i && foo(i) and >> case 1, so they can appear in any order. > Correct, a type pattern `T` should dominate any constant case labels of type T, > but you are right, thsi does not seem to work properly. > Also doesn't work with 17ea: > jshell> int x = 3; switch (x) { case Integer i:} > x ==> 3 > | Error: > | the switch statement does not cover all possible input values > | switch (x) { case Integer i:} > | ^---------------------------^ About the relation between int and Integer, the spec allows boxing but not unboxing, i wonder if we enhance the spec to support unboxing, unboxing being like a pattern query with two possible outcome: do not match if null and match and extract the value if non null. Integer anInteger = ... switch(anInteger) { case null -> // called if null case int i -> // called for non null Integer } and Integer anInteger = ... switch(anInteger) { // NPE if null case int i -> // called for non null Integer } with case Integer dominating case int. R?mi From john.r.rose at oracle.com Sat Sep 4 18:09:24 2021 From: john.r.rose at oracle.com (John Rose) Date: Sat, 4 Sep 2021 18:09:24 +0000 Subject: Dominance in pattern matching for switch: Spec and Javac inconsistency In-Reply-To: <1349000086.2878006.1630677620733.JavaMail.zimbra@u-pem.fr> References: <1942616823.2516329.1630654194683.JavaMail.zimbra@u-pem.fr> <3A25E658-CA11-49B7-AD72-AA556098C2E5@selskabet.org> <1349000086.2878006.1630677620733.JavaMail.zimbra@u-pem.fr> Message-ID: On Sep 3, 2021, at 7:00 AM, forax at univ-mlv.fr wrote: > > > but a guarded switch dominates it's prefix, > e.eg > case Integer i && foo(i) dominates case Integer. > > But there is no rule between a guarded pattern like case Integer i && foo(i) and case 1, so they can appear in any order. > Surely that?s a simple oversight. FWIW, it would be possible to convert reasoning about value-set inclusion to reasoning about type dominance, in this case, by simulating T x && g(x) as an existential type (? extends T). I think that simulation has the right properties for guards, which is that (a) no two guards denote the same static value set and (b) any guarded value set is a subset (possibly improper) of the corresponding unguarded value set. From forax at univ-mlv.fr Mon Sep 6 06:58:28 2021 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Mon, 6 Sep 2021 08:58:28 +0200 (CEST) Subject: Dominance in pattern matching for switch: Spec and Javac inconsistency In-Reply-To: References: <1942616823.2516329.1630654194683.JavaMail.zimbra@u-pem.fr> <3A25E658-CA11-49B7-AD72-AA556098C2E5@selskabet.org> <1349000086.2878006.1630677620733.JavaMail.zimbra@u-pem.fr> Message-ID: <253543138.42386.1630911508336.JavaMail.zimbra@u-pem.fr> ----- Original Message ----- > From: "John Rose" > To: "Remi Forax" > Cc: "Jesper Steen M?ller" , "Ilyas Selimov" , "amber-spec-experts" > > Sent: Samedi 4 Septembre 2021 20:09:24 > Subject: Re: Dominance in pattern matching for switch: Spec and Javac inconsistency > On Sep 3, 2021, at 7:00 AM, forax at univ-mlv.fr wrote: >> >> >> but a guarded switch dominates it's prefix, >> e.eg >> case Integer i && foo(i) dominates case Integer. >> >> But there is no rule between a guarded pattern like case Integer i && foo(i) and >> case 1, so they can appear in any order. >> > > Surely that?s a simple oversight. > > FWIW, it would be possible to convert reasoning about value-set > inclusion to reasoning about type dominance, in this case, by > simulating T x && g(x) as an existential type (? extends T). > > I think that simulation has the right properties for guards, > which is that (a) no two guards denote the same static value > set and (b) any guarded value set is a subset (possibly improper) > of the corresponding unguarded value set. yes, apart that we can detect the case where both guards are identical. something we currently do not do BTW. R?mi From amaembo at gmail.com Mon Sep 6 09:12:50 2021 From: amaembo at gmail.com (Tagir Valeev) Date: Mon, 6 Sep 2021 16:12:50 +0700 Subject: Reiterate total pattern accepting null in switch Message-ID: Hello! Now, as we develop support in IntelliJ, we have a little bit of experience with patterns in switches. So far, the thing I dislike the most is that the total pattern matches null in the switch. I shared my concerns before and now they are basically the same, probably even stronger. Note that I'm not against total pattern matching null in general (e.g., as a nested pattern in deconstruction). But I still think that matching it at the top level of the switch is a mistake. Mentally, the total pattern is close to the default case. It's just more explicit and allows introducing a variable which could be convenient if the selector expression is something complex, like a method call. But the asymmetry in null handling adds confusion. Also, adding a guard means that we do not receive null at this branch anymore which is also confusing. E.g., `case Object obj` accepts null but `case Object obj && obj != null` is meaningless as `obj != null` is always true. Well, making the pattern non-total immediately requires adding a default case, so you cannot just add a guard and do nothing else. Still, it's mentally confusing: switch(x) { ... other cases case Object obj -> ... // null goes here } switch(x) { ... other cases case Object obj && obj != null -> ... // exclude null default -> // add default, as compiler requests. Now only 'null' is the remainder. But why it doesn't go here? } Finally, it complicates the automatic code analysis: to understand whether a given switch throws NPE unconditionally, we need to resolve all the pattern types and evaluate the type of selector expression. This limits our ability for interprocedural analysis, as for performance reasons, we can resolve references in the currently edited file only. I still think that only an explicit 'null' label should turn the switch into null-friendly mode. What do other experts think about this? Am I the only one who doesn't like this? In general, I'm very positive about pattern matching in switches. Aside from this nullability problem, everything else looks fine to me. With best regards, Tagir Valeev. From brian.goetz at oracle.com Mon Sep 6 13:23:41 2021 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 6 Sep 2021 09:23:41 -0400 Subject: Dominance in pattern matching for switch: Spec and Javac inconsistency In-Reply-To: <253543138.42386.1630911508336.JavaMail.zimbra@u-pem.fr> References: <1942616823.2516329.1630654194683.JavaMail.zimbra@u-pem.fr> <3A25E658-CA11-49B7-AD72-AA556098C2E5@selskabet.org> <1349000086.2878006.1630677620733.JavaMail.zimbra@u-pem.fr> <253543138.42386.1630911508336.JavaMail.zimbra@u-pem.fr> Message-ID: > yes, > apart that we can detect the case where both guards are identical. > > something we currently do not do BTW. > That we don't do that now is a deliberate choice.? Even this is stepping onto the slippery slope; the ability to reason about guards falls off a cliff pretty quickly, and I'm not sure that handling the "easy cases" is doing the user a favor, when it risks lulling them into a false sense of confidence.? (We see this all the time with type inference; the better type inference is, the more upset people get when it doesn't read their mind.) We could "easily" handle this: ??? case int i && i > 0: ??? case int i && i <= 0; (and some languages do.)? But even the short hop to ??? case int i && (i %2) == 0: ??? case int i && (i %2) == 1; is harder.? IntelliJ does heroics with abstract interpretation to find these things, which is great for an IDE, but less appropriate for a language spec.? So the question is, if we're going to venture onto that field, where do we draw the line?? Even "you specified exactly the same guard", once you get beyond a purely lexical definition of "same", is going to have holes. The danger of attempting something so inherently incomplete is that we will invariably get drawn into a stream of "you do it here, but not there, that's a bug", which leads either to resources invested in low-value extensions, or low-value arguments about why we're not going to take then 342nd step (because, you already took the previous 341!) So for now, we've drawn the line at "we're not gonna try"; we can always try harder later, since all that will do is make some switches that were already total but we didn't know it, into "total and we know it." From brian.goetz at oracle.com Mon Sep 6 13:46:19 2021 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 6 Sep 2021 09:46:19 -0400 Subject: Reiterate total pattern accepting null in switch In-Reply-To: References: Message-ID: <425fec2f-098e-4b05-c814-acf74aa7bb44@oracle.com> On 9/6/2021 5:12 AM, Tagir Valeev wrote: > Hello! > > Now, as we develop support in IntelliJ, we have a little bit of > experience with patterns in switches. So far, the thing I dislike the > most is that the total pattern matches null in the switch. I shared my > concerns before and now they are basically the same, probably even > stronger. Note that I'm not against total pattern matching null in > general (e.g., as a nested pattern in deconstruction). But I still > think that matching it at the top level of the switch is a mistake. > Mentally, the total pattern is close to the default case. I think there are several issues here; let's try to tease them apart. The main problem, as I see it, is not one of whether we picked the right default, or whether that default is unfamiliar (though these are both valid things to discuss), but that we are putting the user to a non-orthogonal choice.? They can say: ??? case Object o: and get binding and null-matching, or ??? default: and get neither binding nor null-matching. In some way, you are saying that there is a significant contingency where users want binding but not null-matching, and we're forcing users to take a package deal.? As a thought experiment, how differently would you feel if we had both nullable and non-nullable type patterns: ??? case String! s: ??? case String? s: If we had the ability to refine the match in this way, then the choice of binding and null handling would be orthogonal: ??? case Object! o:?? // binding, no null ??? case Object? o:?? // binding, null ??? default:????????? // no binding, no null ??? null, default:??? // no binding, null So the first thought experiment I am asking you to do is whether, in this world, you would feel significantly differently. > Also, > adding a guard means that we do not receive null at this branch > anymore which is also confusing. Good point, I'll think on this a bit. To reiterate the motivation, the thing we're going for here is the consistency that a switch of nested patterns and a nested switch are the same: ??? case Box(Foo f): ??? case Box(Object o): is the same as ??? case Box b: ??????? switch (b.get()) { ??????????? case Foo f: ??????????? case Object o: ??????? } ??? } If we treat the null at the top level, we get a different kind of asymmetry.? What we're banking on (which could be wrong) is that its better to rip off the band-aid rather than cater to legacy assumptions about switch. I think what you are saying here is that switch is so weird that it is just a matter of pick your asymmetry, and the argument for moving it to the top level is that this is weirdness people are already used to.? This may be true, though I worry that it is just that people are not *yet* used to nested switches, but they'll be annoyed when they get bit by refactoring issues. > E.g., `case Object obj` accepts null > but `case Object obj && obj != null` is meaningless as `obj != null` > is always true. Well, making the pattern non-total immediately > requires adding a default case, so you cannot just add a guard and do > nothing else. Still, it's mentally confusing: > > switch(x) { > ... other cases > case Object obj -> ... // null goes here > } > > switch(x) { > ... other cases > case Object obj && obj != null -> ... // exclude null > default -> // add default, as compiler requests. Now only 'null' is > the remainder. But why it doesn't go here? > } OK, but write those cases out nested one level in Box(); are you not equally unhappy there? From forax at univ-mlv.fr Mon Sep 6 19:51:17 2021 From: forax at univ-mlv.fr (Remi Forax) Date: Mon, 6 Sep 2021 21:51:17 +0200 (CEST) Subject: Reiterate total pattern accepting null in switch In-Reply-To: <425fec2f-098e-4b05-c814-acf74aa7bb44@oracle.com> References: <425fec2f-098e-4b05-c814-acf74aa7bb44@oracle.com> Message-ID: <1469563707.541865.1630957877558.JavaMail.zimbra@u-pem.fr> ----- Original Message ----- > From: "Brian Goetz" > To: "Tagir Valeev" , "amber-spec-experts" > Sent: Lundi 6 Septembre 2021 15:46:19 > Subject: Re: Reiterate total pattern accepting null in switch > On 9/6/2021 5:12 AM, Tagir Valeev wrote: >> Hello! >> >> Now, as we develop support in IntelliJ, we have a little bit of >> experience with patterns in switches. So far, the thing I dislike the >> most is that the total pattern matches null in the switch. I shared my >> concerns before and now they are basically the same, probably even >> stronger. Note that I'm not against total pattern matching null in >> general (e.g., as a nested pattern in deconstruction). But I still >> think that matching it at the top level of the switch is a mistake. >> Mentally, the total pattern is close to the default case. > > I think there are several issues here; let's try to tease them apart. > > The main problem, as I see it, is not one of whether we picked the right > default, or whether that default is unfamiliar (though these are both > valid things to discuss), but that we are putting the user to a > non-orthogonal choice.? They can say: > > ??? case Object o: > > and get binding and null-matching, or > > ??? default: > > and get neither binding nor null-matching. > > In some way, you are saying that there is a significant contingency > where users want binding but not null-matching, and we're forcing users > to take a package deal.? As a thought experiment, how differently would > you feel if we had both nullable and non-nullable type patterns: > > ??? case String! s: > ??? case String? s: > > If we had the ability to refine the match in this way, then the choice > of binding and null handling would be orthogonal: > > ??? case Object! o:?? // binding, no null > ??? case Object? o:?? // binding, null > ??? default:????????? // no binding, no null > ??? null, default:??? // no binding, null > > So the first thought experiment I am asking you to do is whether, in > this world, you would feel significantly differently. There is no binding available for "default" but the selector value of the switch is available. switch(anObject) { default: // no binding but one can use 'anObject' directly } so i'm not sure to fully understand the point your are trying to make. > >> Also, >> adding a guard means that we do not receive null at this branch >> anymore which is also confusing. > > Good point, I'll think on this a bit. yes, if there is no default, the type pattern for a case which is not the last and the type pattern for the last case has a different meaning (for the record i'm fine with that), but combined with the current rules for the guarded patterns, this has some puzzling side effects. By example, using a guard that is simple enough for a human to see it is always true but not simple enough for the compiler so it is not constant folded, switch(x) { ... other cases case Object obj && x == x -> ... // exclude null case Object obj -> // null goes here } > > To reiterate the motivation, the thing we're going for here is the > consistency that a switch of nested patterns and a nested switch are the > same: > > ??? case Box(Foo f): > ??? case Box(Object o): > > is the same as > > ??? case Box b: > ??????? switch (b.get()) { > ??????????? case Foo f: > ??????????? case Object o: > ??????? } > ??? } > > If we treat the null at the top level, we get a different kind of > asymmetry.? What we're banking on (which could be wrong) is that its > better to rip off the band-aid rather than cater to legacy assumptions > about switch. And also we want to keep the legacy semantics of "default", we do not want the existing "default" inside the switch on String/Enum to have a different behavior from the existing ones. > > I think what you are saying here is that switch is so weird that it is > just a matter of pick your asymmetry, and the argument for moving it to > the top level is that this is weirdness people are already used to. > This may be true, though I worry that it is just that people are not > *yet* used to nested switches, but they'll be annoyed when they get bit > by refactoring issues. And there is also actually no way to write "case var o" which is IMHO the explicit way to convey the fact that the last case is total. Using "case var o" in all the examples above make the codes readable. I think the real issue here is that we are in the middle of introducing the different patterns, so the big picture is not in front of us yet. [...] R?mi From john.r.rose at oracle.com Mon Sep 6 21:09:09 2021 From: john.r.rose at oracle.com (John Rose) Date: Mon, 6 Sep 2021 21:09:09 +0000 Subject: Dominance in pattern matching for switch: Spec and Javac inconsistency In-Reply-To: References: <1942616823.2516329.1630654194683.JavaMail.zimbra@u-pem.fr> <3A25E658-CA11-49B7-AD72-AA556098C2E5@selskabet.org> <1349000086.2878006.1630677620733.JavaMail.zimbra@u-pem.fr> <253543138.42386.1630911508336.JavaMail.zimbra@u-pem.fr> Message-ID: FTR, I approve of not even stepping onto this slippery slope. Doing so would seem to promise something of value to users, a promise they?d probably feel we would break by the draconian restrictions (with or without complex case analysis on statically kennable expressions). Remi, this relates to your offhand comment about guards which are always true, as in case T x && alwaysTrue(x) vs. case T (no guard). Detecting always-true guards is about the same problem (with no solution) as detecting equivalent guards. In particular if G1 and G2 are somehow provably equivalent then G1==G2 is provably true and G1!=G2 is provably false. If G0 is provably true, then G1 and G1&G0 are provably equivalent, and so on. Statically, a guard should be treated as a coin flip independent of every other expression. (See also my comment about guards working, in static analysis, like existential subtypes of the guarded type.) ? John > On Sep 6, 2021, at 6:23 AM, Brian Goetz wrote: > > >> yes, >> apart that we can detect the case where both guards are identical. >> >> something we currently do not do BTW. >> > > That we don't do that now is a deliberate choice. Even this is stepping onto the slippery slope; the ability to reason about guards falls off a cliff pretty quickly, and I'm not sure that handling the "easy cases" is doing the user a favor, when it risks lulling them into a false sense of confidence. (We see this all the time with type inference; the better type inference is, the more upset people get when it doesn't read their mind.) > > We could "easily" handle this: > > case int i && i > 0: > case int i && i <= 0; > > (and some languages do.) But even the short hop to > > case int i && (i %2) == 0: > case int i && (i %2) == 1; > > is harder. IntelliJ does heroics with abstract interpretation to find these things, which is great for an IDE, but less appropriate for a language spec. So the question is, if we're going to venture onto that field, where do we draw the line? Even "you specified exactly the same guard", once you get beyond a purely lexical definition of "same", is going to have holes. > > The danger of attempting something so inherently incomplete is that we will invariably get drawn into a stream of "you do it here, but not there, that's a bug", which leads either to resources invested in low-value extensions, or low-value arguments about why we're not going to take then 342nd step (because, you already took the previous 341!) > > So for now, we've drawn the line at "we're not gonna try"; we can always try harder later, since all that will do is make some switches that were already total but we didn't know it, into "total and we know it." > > From john.r.rose at oracle.com Mon Sep 6 21:14:40 2021 From: john.r.rose at oracle.com (John Rose) Date: Mon, 6 Sep 2021 21:14:40 +0000 Subject: Dominance in pattern matching for switch: Spec and Javac inconsistency In-Reply-To: References: <1942616823.2516329.1630654194683.JavaMail.zimbra@u-pem.fr> <3A25E658-CA11-49B7-AD72-AA556098C2E5@selskabet.org> <1349000086.2878006.1630677620733.JavaMail.zimbra@u-pem.fr> <253543138.42386.1630911508336.JavaMail.zimbra@u-pem.fr>

Message-ID: <908BD727-1128-473C-9E8D-250EE8D73A2D@oracle.com> P.S. If a Java expression X is (for whatever reason) compiled to an indy instruction, and that instruction has a BSM that flips coins or bumps counters or uses resources, then *two identical copies* of X will not be equivalent. (This relates to some conversation Brian and I had about ?constant expressions?, along the lines of ?how constant does a constant expression need to be?? One aspect of that set of problems is that the user often expects to be able to use the value of a constant expression in multiple places, at least in some desugaring schemes, so it should be clone-able without loss of information; that lets us write the desugaring without generating static temp variables. But an indy-generating expression is not clone-able, unless its BSM is constrained somehow.) On Sep 6, 2021, at 2:09 PM, John Rose > wrote: FTR, I approve of not even stepping onto this slippery slope. Doing so would seem to promise something of value to users, a promise they?d probably feel we would break by the draconian restrictions (with or without complex case analysis on statically kennable expressions). Remi, this relates to your offhand comment about guards which are always true, as in case T x && alwaysTrue(x) vs. case T (no guard). Detecting always-true guards is about the same problem (with no solution) as detecting equivalent guards. In particular if G1 and G2 are somehow provably equivalent then G1==G2 is provably true and G1!=G2 is provably false. If G0 is provably true, then G1 and G1&G0 are provably equivalent, and so on. Statically, a guard should be treated as a coin flip independent of every other expression. (See also my comment about guards working, in static analysis, like existential subtypes of the guarded type.) ? John From forax at univ-mlv.fr Tue Sep 7 13:41:51 2021 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Tue, 7 Sep 2021 15:41:51 +0200 (CEST) Subject: Dominance in pattern matching for switch: Spec and Javac inconsistency In-Reply-To: <908BD727-1128-473C-9E8D-250EE8D73A2D@oracle.com> References: <3A25E658-CA11-49B7-AD72-AA556098C2E5@selskabet.org> <1349000086.2878006.1630677620733.JavaMail.zimbra@u-pem.fr> <253543138.42386.1630911508336.JavaMail.zimbra@u-pem.fr>

<908BD727-1128-473C-9E8D-250EE8D73A2D@oracle.com> Message-ID: <1315587075.910274.1631022111924.JavaMail.zimbra@u-pem.fr> > From: "John Rose" > To: "Brian Goetz" > Cc: "Remi Forax" , "Jesper Steen M?ller" > , "Ilyas Selimov" , > "amber-spec-experts" > Sent: Lundi 6 Septembre 2021 23:14:40 > Subject: Re: Dominance in pattern matching for switch: Spec and Javac > inconsistency > P.S. If a Java expression X is (for whatever reason) > compiled to an indy instruction, and that instruction > has a BSM that flips coins or bumps counters or > uses resources, then *two identical copies* of X > will not be equivalent. > (This relates to some conversation Brian and I > had about ?constant expressions?, along the lines > of ?how constant does a constant expression need > to be?? One aspect of that set of problems is that > the user often expects to be able to use the value > of a constant expression in multiple places, at > least in some desugaring schemes, so it should > be clone-able without loss of information; that > lets us write the desugaring without generating > static temp variables. But an indy-generating > expression is not clone-able, unless its BSM is > constrained somehow.) BSM used by Java (the language) has to be constrained anyway, otherwise you loose the part of the ecosystem that relies on static analysis to work, Graal native image or Android, come to my mind. I don't think any future Java translation strategies can use a BSM which is not refentially transparent. BTW, it's why i want the implementation of the translation strategy for the switch to share prefix patterns, at runtime, you execute only one expression for one pattern even if the same pattern is present in different cases, so you do not have to clone things. The drawback is that you have to transform every patterns (the thingy defined between "case" and ":"/"->") to a method handle at runtime, so peak performance is not an issue but startup is slow. R?mi >> On Sep 6, 2021, at 2:09 PM, John Rose < [ mailto:john.r.rose at oracle.com | >> john.r.rose at oracle.com ] > wrote: >> FTR, I approve of not even stepping onto this slippery >> slope. Doing so would seem to promise something of >> value to users, a promise they?d probably feel we would >> break by the draconian restrictions (with or without >> complex case analysis on statically kennable expressions). >> Remi, this relates to your offhand comment about guards >> which are always true, as in case T x && alwaysTrue(x) >> vs. case T (no guard). Detecting always-true guards is >> about the same problem (with no solution) as detecting >> equivalent guards. In particular if G1 and G2 are somehow >> provably equivalent then G1==G2 is provably true and >> G1!=G2 is provably false. If G0 is provably true, then >> G1 and G1&G0 are provably equivalent, and so on. >> Statically, a guard should be treated as a coin flip >> independent of every other expression. (See also >> my comment about guards working, in static >> analysis, like existential subtypes of the guarded >> type.) >> ? John From amaembo at gmail.com Wed Sep 8 05:15:19 2021 From: amaembo at gmail.com (Tagir Valeev) Date: Wed, 8 Sep 2021 12:15:19 +0700 Subject: Reiterate total pattern accepting null in switch In-Reply-To: <425fec2f-098e-4b05-c814-acf74aa7bb44@oracle.com> References: <425fec2f-098e-4b05-c814-acf74aa7bb44@oracle.com> Message-ID: Hello! > case Object! o: // binding, no null > case Object? o: // binding, null > default: // no binding, no null > null, default: // no binding, null > > So the first thought experiment I am asking you to do is whether, in > this world, you would feel significantly differently. This is definitely more clear, at least you have a visual sign that null is allowed there, and don't need any bigger context. Also, Kotlin programming experience helps here. However, this will allow introducing several null-friendly branches: case String? s -> ... case Number? n -> ... Now, we can do this with case null, String s -> ... case null, Number n -> ... And it's much more clear that something is wrong (and compiler error will be perfectly clear). When using the question mark, it's not clear whether we should prohibit this (as both cases are actually populated). In other words, this syntax would introduce its own problems. Though probably, it's justified to explore this syntax again, as we are approaching nested patterns. I'm not sure whether we need `Object!` though, just `Object` (non-null by default) would be enough. Also, having "String? s" pattern would allow enhancing instanceof to match null. Sometimes, it's really useful. In IntelliJ sources, we have 388 conditions like `$x$ == null || $x$ instanceof $t$`. Well, in most of the cases, the binding variable is unnecessary (it's usually like if(x == null || x instanceof SomeWrongType) return false) > To reiterate the motivation, the thing we're going for here is the > consistency that a switch of nested patterns and a nested switch are the > same: > > case Box(Foo f): > case Box(Object o): > > is the same as > > case Box b: > switch (b.get()) { > case Foo f: > case Object o: > } > } Yes, I remember that the motivation was like this. > If we treat the null at the top level, we get a different kind of > asymmetry. What we're banking on (which could be wrong) is that its > better to rip off the band-aid rather than cater to legacy assumptions > about switch. > > I think what you are saying here is that switch is so weird that it is > just a matter of pick your asymmetry, and the argument for moving it to > the top level is that this is weirdness people are already used to. Yes, exactly! > This may be true, though I worry that it is just that people are not > *yet* used to nested switches, but they'll be annoyed when they get bit > by refactoring issues. Probably you're right. > OK, but write those cases out nested one level in Box(); are you not > equally unhappy there? It's interesting. Let's assume we have Box, so String s is total on the box component. Am I correct in the interpretation of the following patterns? case Box(String s && s.isEmpty()) // String s && s.isEmpty() is not total on the box component, so Box(null) is not matched here case Box(String s) && s.isEmpty() // String s is total on the box component, so Box(null) is matched in nested pattern, and s.isEmpty() will produce NPE If yes, then yes, it's confusing. Here, having String? (to allow nulls) and String (to disallow nulls regardless of totality) would definitely make things more clear. With best regards, Tagir Valeev From forax at univ-mlv.fr Wed Sep 8 06:42:29 2021 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 8 Sep 2021 08:42:29 +0200 (CEST) Subject: merging cases in between values and types Message-ID: <2062013998.1180753.1631083349599.JavaMail.zimbra@u-pem.fr> Hi all, the current spec support merging/fallthrough cases only when there is a case null, like case null, case Integer i -> // i can use 'i' here First, i'm not sure it's clearly written in the spec, i was not able to pinpoint the rule allowing it. Then i wonder if this special behavior is special because null is special or if it should work with any values of the type of the type pattern, i.e. it works because null is a possible value of Integer, in that case, it should also work with any other values like 42 case 42, case Integer i -> // i can use 'i' here So is null a special value or does this rule also work with any values. regards, R?mi From brian.goetz at oracle.com Wed Sep 8 15:08:59 2021 From: brian.goetz at oracle.com (Brian Goetz) Date: Wed, 8 Sep 2021 11:08:59 -0400 Subject: merging cases in between values and types In-Reply-To: <2062013998.1180753.1631083349599.JavaMail.zimbra@u-pem.fr> References: <2062013998.1180753.1631083349599.JavaMail.zimbra@u-pem.fr> Message-ID: It doesn't really matter, since 42 is subsumed into Integer anyway.? Null is the weirdo (as always.) On 9/8/2021 2:42 AM, Remi Forax wrote: > Hi all, > the current spec support merging/fallthrough cases only when there is a case null, > like > case null, case Integer i -> // i can use 'i' here > > First, i'm not sure it's clearly written in the spec, i was not able to pinpoint the rule allowing it. > Then i wonder if this special behavior is special because null is special or if it should work with any values of the type of the type pattern, > i.e. it works because null is a possible value of Integer, in that case, it should also work with any other values like 42 > > case 42, case Integer i -> // i can use 'i' here > > So is null a special value or does this rule also work with any values. > > regards, > R?mi > > From forax at univ-mlv.fr Wed Sep 8 16:15:18 2021 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Wed, 8 Sep 2021 18:15:18 +0200 (CEST) Subject: merging cases in between values and types In-Reply-To: References: <2062013998.1180753.1631083349599.JavaMail.zimbra@u-pem.fr> Message-ID: <1092846518.1624345.1631117718550.JavaMail.zimbra@u-pem.fr> > From: "Brian Goetz" > To: "Remi Forax" , "amber-spec-experts" > > Sent: Mercredi 8 Septembre 2021 17:08:59 > Subject: Re: merging cases in between values and types > It doesn't really matter, since 42 is subsumed into Integer anyway. Null is the > weirdo (as always.) ??, currently we allow null but not 42. R?mi > On 9/8/2021 2:42 AM, Remi Forax wrote: >> Hi all, >> the current spec support merging/fallthrough cases only when there is a case >> null, >> like >> case null, case Integer i -> // i can use 'i' here >> First, i'm not sure it's clearly written in the spec, i was not able to pinpoint >> the rule allowing it. >> Then i wonder if this special behavior is special because null is special or if >> it should work with any values of the type of the type pattern, >> i.e. it works because null is a possible value of Integer, in that case, it >> should also work with any other values like 42 >> case 42, case Integer i -> // i can use 'i' here >> So is null a special value or does this rule also work with any values. >> regards, >> R?mi From amaembo at gmail.com Sat Sep 11 06:28:07 2021 From: amaembo at gmail.com (Tagir Valeev) Date: Sat, 11 Sep 2021 13:28:07 +0700 Subject: Using switch patterns to rewrite Arrays.deepHashCode Message-ID: Hello! I just was thinking about good samples where switch patterns could be useful. One idea I have is Arrays.deepHashCode. The current implementation uses a helper method and queries getClass(): public static int deepHashCode(Object a[]) { if (a == null) return 0; int result = 1; for (Object element : a) { final int elementHash; final Class cl; if (element == null) elementHash = 0; else if ((cl = element.getClass().getComponentType()) == null) elementHash = element.hashCode(); else if (element instanceof Object[]) elementHash = deepHashCode((Object[]) element); else elementHash = primitiveArrayHashCode(element, cl); result = 31 * result + elementHash; } return result; } private static int primitiveArrayHashCode(Object a, Class cl) { return (cl == byte.class) ? hashCode((byte[]) a) : (cl == int.class) ? hashCode((int[]) a) : (cl == long.class) ? hashCode((long[]) a) : (cl == char.class) ? hashCode((char[]) a) : (cl == short.class) ? hashCode((short[]) a) : (cl == boolean.class) ? hashCode((boolean[]) a) : (cl == double.class) ? hashCode((double[]) a) : // If new primitive types are ever added, this method must be // expanded or we will fail here with ClassCastException. hashCode((float[]) a); } It can be simplified with patterns: public static int deepHashCode(Object[] a) { if (a == null) return 0; int result = 1; for (Object element : a) { final int elementHash = switch(element) { case null -> 0; case Object[] arr -> deepHashCode(arr); case byte[] arr -> hashCode(arr); case short[] arr -> hashCode(arr); case char[] arr -> hashCode(arr); case int[] arr -> hashCode(arr); case long[] arr -> hashCode(arr); case float[] arr -> hashCode(arr); case double[] arr -> hashCode(arr); default -> element.hashCode(); }; result = 31 * result + elementHash; } return result; } Here we see good use of case null. One problem is the possible (though unlikely) appearance of new primitive types. In this case, the default branch will be silently taken. Well, we can add an assert: default -> { assert !element.getClass().isArray(); yield element.hashCode(); } Probably we need a sealed supertype for all arrays that permits all final primitive subtypes and non-sealed Object[] subtype? In this case, we could make a sub-switch and rely on the compiler: final int elementHash = switch(element) { case null -> 0; case AnyArray anyArray -> switch(anyArray) { case Object[] arr -> deepHashCode(arr); case byte[] arr -> hashCode(arr); case short[] arr -> hashCode(arr); case char[] arr -> hashCode(arr); case int[] arr -> hashCode(arr); case long[] arr -> hashCode(arr); case float[] arr -> hashCode(arr); case double[] arr -> hashCode(arr); // no default case! }; default -> element.hashCode(); }; Well, this is probably a huge amount of work with little benefit, though probably something similar is being baked in Valhalla? In any case, I like the new version more than the original one. With best regards, Tagir Valeev. From brian.goetz at oracle.com Sat Sep 11 13:48:05 2021 From: brian.goetz at oracle.com (Brian Goetz) Date: Sat, 11 Sep 2021 09:48:05 -0400 Subject: Using switch patterns to rewrite Arrays.deepHashCode In-Reply-To: References: Message-ID: <9591aa13-766d-523a-4c55-fdb6699e9ab8@oracle.com> Thanks Tagir, this is a helpful exploration.? There are lots of places in the JDK (and the world beyond) that assume "eight primitive types, no more"; finding them is a game of whack-a-mole.? The real question is how many of them would fall back to something reasonable when the ninth primitive shows up, vs how many would blow up. THe good news is that, because primitives extend Object, code that says "do X for primitives, otherwise fall back to Object::hashCode (or ::toString or whatever) is likely to usually work. A synthetic "array" supertype is something we've discussed a few times, but always got distracted before coming to any conclusions. > final int elementHash = switch(element) { > case null -> 0; > case AnyArray anyArray -> switch(anyArray) { > case Object[] arr -> deepHashCode(arr); > case byte[] arr -> hashCode(arr); > case short[] arr -> hashCode(arr); > case char[] arr -> hashCode(arr); > case int[] arr -> hashCode(arr); > case long[] arr -> hashCode(arr); > case float[] arr -> hashCode(arr); > case double[] arr -> hashCode(arr); > // no default case! > }; > default -> element.hashCode(); > }; You would need to reorder this switch!? Because byte[] will be a subtype of Object[]. From john.r.rose at oracle.com Sat Sep 11 18:42:02 2021 From: john.r.rose at oracle.com (John Rose) Date: Sat, 11 Sep 2021 18:42:02 +0000 Subject: Using switch patterns to rewrite Arrays.deepHashCode In-Reply-To: <9591aa13-766d-523a-4c55-fdb6699e9ab8@oracle.com> References: <9591aa13-766d-523a-4c55-fdb6699e9ab8@oracle.com> Message-ID: <813AD5A4-7FDD-4779-99CA-10FC688CBDA6@oracle.com> On Sep 11, 2021, at 6:48 AM, Brian Goetz > wrote: You would need to reorder this switch! Because byte[] will be a subtype of Object[]. In Valhalla, that is. Putting Object[] at the bottom will absorb any and all ?new primitives?. In fact, the ?old primitives? will also be absorbed by Object[], so in Valhalla the switch statement is not required, but may be simply a hand-optimization (to get hand-specialized code for some known types). That sort of hand-optimization wants to be replaced by JVM and language support for template-like specialization. Putting Object[] at the top forces a re-evaluation when Valhalla comes, since the code will break. From john.r.rose at oracle.com Sat Sep 11 18:48:15 2021 From: john.r.rose at oracle.com (John Rose) Date: Sat, 11 Sep 2021 18:48:15 +0000 Subject: Using switch patterns to rewrite Arrays.deepHashCode In-Reply-To: <813AD5A4-7FDD-4779-99CA-10FC688CBDA6@oracle.com> References: <9591aa13-766d-523a-4c55-fdb6699e9ab8@oracle.com> <813AD5A4-7FDD-4779-99CA-10FC688CBDA6@oracle.com> Message-ID: On Sep 11, 2021, at 11:42 AM, John Rose > wrote: Putting Object[] at the top forces a re-evaluation when Valhalla comes, since the code will break. P.S. I wonder if there is a compatibility move where errors which arise from changed type relations (int <: Object) are downgraded to warnings, at least for a while. That would cause a dominating `case Object[] x:` to warn not error. I think I can hear Dan saying, ?ehh, not worth the trouble.? From gavin.bierman at oracle.com Mon Sep 13 15:00:09 2021 From: gavin.bierman at oracle.com (Gavin Bierman) Date: Mon, 13 Sep 2021 15:00:09 +0000 Subject: merging cases in between values and types In-Reply-To: <2062013998.1180753.1631083349599.JavaMail.zimbra@u-pem.fr> References: <2062013998.1180753.1631083349599.JavaMail.zimbra@u-pem.fr> Message-ID: <63C9A991-8498-40E9-8985-A7A9ECAEC1A9@oracle.com> Hi Remi, Sorry for the slow reply: > On 8 Sep 2021, at 07:42, Remi Forax wrote: > > Hi all, > the current spec support merging/fallthrough cases only when there is a case null, > like > case null, case Integer i -> // i can use 'i' here > > First, i'm not sure it's clearly written in the spec, i was not able to pinpoint the rule allowing it. In 14.11.1 there is a bunch of well-formedness conditions listed for switch labels. The paragraph begins ?For every switch label in a switch block, all of the following must be true, otherwise a compile-time error occurs?? What follows is a bunch of rules that spell out which switch labels are correctly formed, and which are not. The two rules that cover your question here are: ? If a switch label has a constant case label element then if the switch label also has other case element labels they must be either a constant case label element, the default case label element, or the null case label element. and ? If a switch label has a null case label element then if the switch label also has any pattern case element labels, they must be type patterns (14.30.1). So the first rule forbids you from writing case 42, Integer i. The second rule allows you to say case null, Integer i (and case Integer i, null actually.) So, yes, the null is treated specially. Indeed it?s behaviour is NOT about fall through really. When you write case null, Foo f you are not asking for the type pattern test to be carried out if the value is null (it might fail!). Nor are you asking for it to be ignored (cos then the pattern variable will not be initialised). You?re actually saying ?if it?s null then it matches AND the variable i is initialised to null?. So it?s being treated like a special pattern label. If we were to give it an alternative syntax, we might write ?case Foo? f? instead of ?case null, Foo f?. Hope this helps, Gavin > Then i wonder if this special behavior is special because null is special or if it should work with any values of the type of the type pattern, > i.e. it works because null is a possible value of Integer, in that case, it should also work with any other values like 42 > > case 42, case Integer i -> // i can use 'i' here > > So is null a special value or does this rule also work with any values. > > regards, > R?mi > > From forax at univ-mlv.fr Tue Sep 14 08:38:31 2021 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 14 Sep 2021 10:38:31 +0200 (CEST) Subject: Factory methods & the language model In-Reply-To: <617ab0ce-4a93-7705-77c1-039cbae21676@oracle.com> References: <83A0DA05-45F2-43FB-9E67-7DEEFD46BB34@oracle.com> <865F5DDA-9A4D-4144-9162-B3FC46533A64@oracle.com> <67D21363-2592-426D-AE58-ECCE2E072DE3@oracle.com>

<617ab0ce-4a93-7705-77c1-039cbae21676@oracle.com> Message-ID: <173911978.797118.1631608711740.JavaMail.zimbra@u-pem.fr> ----- Original Message ----- > From: "Brian Goetz" > To: "daniel smith" , "Dan Heidinga" > Cc: "valhalla-spec-experts" > Sent: Vendredi 10 Septembre 2021 20:25:50 > Subject: Re: Factory methods & the language model >> I'm not particularly interested in settling on a bikeshed color, but am >> interested in the general mood for pursuing this direction at all. (And not >> necessarily right away, just?is this a direction we think we'll be going?) >> >> A few observations/questions: >> >> - 'new Foo()' traditionally guarantees fresh instance creation for identity >> classes. Primitive classes relax this, since of course there is no unique >> identity to talk about. Would we be happy with a language that relaxes this >> further, such that 'new Foo()' can return an arbitrary Foo instance (or maybe >> even null)? Or would we want to pursue a different, factory-specific invocation >> syntax? (And if so, should primitive classes use it too?) > > Let me offer some context from Amber that might be helpful, regarding > whether we might want "factory" to be a language feature. > [...] > > Example 2 -- "with" expressions / reconstructors.? A number of > interesting features come out of the pairing of constructors and > deconstruction patterns with the same (or compatible) argument lists, > such as `with` expressions (`point with { x = 3 }`). Handling this > involves doing multiple overload selection operations, first to find a > deconstructor that yields the right bindings, and then to find a > compatible constructor that accepts the resulting exploded state. > > Among the many problems of doing this (including the fact that parameter > names are not required to be stable or meaningful), we also have the > problem of "what if the class doesn't have a constructor, but a > factory."? This would require the language to have a notion of factory > method (e.g., `factory newPoint(int x, int y)`) so the compiler could > try to match up a compatible factory with the deconstructor. I think there is a way to not introduce a weird with expression syntax by piggybacking on the fact that a record is a weird tuple. A record in Java is not just a tuple, i.e. a vector of values, but because all components are named also a compact key/value set. The "with" expression is a case where we want to see a record as key/value set more than as a vector of values. If we have a syntax to construct a record as a key/value set, this syntax can be slightly extended to express a "with" expression. By example, if we have a syntax like Point p = Point { x: 3, y: 4 }; Then the syntax for the with expression will be to something like Point p2 = Point { x: 7, p }; I can hear you saying that i'm trying to trick you to add a new syntax for creating a record which is bigger that just the "with" expression. And that's partially true. I believe that the "key/value set" syntax for a record is something we should introduce in Amber anyway because it's a declarative syntax, the same way a Stream is, making the code easier to read. And people want a syntax like this so badly that they are up to writing a full builder pattern in their code just for being able to see the name of the parameters when creating complex objects. regards, R?mi From gavin.bierman at oracle.com Tue Sep 14 16:03:24 2021 From: gavin.bierman at oracle.com (Gavin Bierman) Date: Tue, 14 Sep 2021 16:03:24 +0000 Subject: Fwd: Dominance in pattern matching for switch: Spec and Javac inconsistency References: <04A1BD76-E178-4F6E-A0F0-C321A8C49C52@oracle.com> Message-ID: <07F85643-64E5-4685-AF0F-15429401FF7A@oracle.com> Begin forwarded message: From: Gavin Bierman > Subject: Re: Dominance in pattern matching for switch: Spec and Javac inconsistency Date: 14 September 2021 at 17:02:50 BST To: Ilyas Selimov > Cc: "compiler-dev at openjdk.java.net" > Thanks Ilyas, Yes, this is a small bug in the spec which is causing your confusion. When it was first drafted it there was only one pattern case label element - a type pattern. By the time we published, there were two more - parenthesised patterns and guarded patterns. The rule didn?t get updated :-( The rule you read only applies to *type* patterns. We need a couple of extra rules for parenthesised and guarded patterns. As it happens the compiler is correct here. We treat a guarded pattern as a subset pattern, unless the guard is a constant expression whose value is true (a rare case!). So, in your example, we see that the first pattern matches *some* integers. We don?t know which ones, so we can?t be sure that it dominates the integer value 1. So the code is correct. We could attempt to look at the guards to see what we can infer statically, but I think this unlikely to be a fruitful direction to take. Thanks, Gavin On 3 Sep 2021, at 06:27, Ilyas Selimov > wrote: Hello! The next code compiles correctly, but it seems to contradict the dominance rules: void test(Integer i) { switch (i) { case Integer in && in != null: break; case 1: break; case default: break; } } A switch label that has a pattern case label element p dominates another switch label that has a constant case label element c if either of the following is true: - the type of c is a primitive type and its wrapper class (5.1.7) is a subtype of the erasure of the type of p. Maybe the type of p should also be total for the type of selector expression like in the rules for pattern-over-null dominance? Thanks, Ilyas From forax at univ-mlv.fr Wed Sep 15 16:06:02 2021 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Wed, 15 Sep 2021 18:06:02 +0200 (CEST) Subject: merging cases in between values and types In-Reply-To: <63C9A991-8498-40E9-8985-A7A9ECAEC1A9@oracle.com> References: <2062013998.1180753.1631083349599.JavaMail.zimbra@u-pem.fr> <63C9A991-8498-40E9-8985-A7A9ECAEC1A9@oracle.com> Message-ID: <1422085677.1699630.1631721962349.JavaMail.zimbra@u-pem.fr> ----- Original Message ----- > From: "Gavin Bierman" > To: "Remi Forax" > Cc: "amber-spec-experts" > Sent: Lundi 13 Septembre 2021 17:00:09 > Subject: Re: merging cases in between values and types > Hi Remi, Hi Gavin, > > Sorry for the slow reply: > >> On 8 Sep 2021, at 07:42, Remi Forax wrote: >> >> Hi all, >> the current spec support merging/fallthrough cases only when there is a case >> null, >> like >> case null, case Integer i -> // i can use 'i' here >> >> First, i'm not sure it's clearly written in the spec, i was not able to pinpoint >> the rule allowing it. > > In 14.11.1 there is a bunch of well-formedness conditions listed for switch > labels. The paragraph begins ?For every switch label in a switch block, all of > the following must be true, otherwise a compile-time error occurs?? What > follows is a bunch of rules that spell out which switch labels are correctly > formed, and which are not. The two rules that cover your question here are: > > > ? If a switch label has a constant case label element then if the switch label > also has other case element labels they must be either a constant case label > element, the default case label element, or the null case label element. > > and > > ? If a switch label has a null case label element then if the switch label also > has any pattern case element labels, they must be type patterns (14.30.1). Thanks, i've overlook the rules of 14.11.1. The last point treat null has a special value, and i'm proposing to extend that rule to any constant not just null, because i don't see why null is a special case (sorry) here. This rule works because the type of null is a subtype of all the types. But we know that while this is true now, it will not be true in the future when we will introduce the primitive class. So instead of adding a special rule for null now to specialize it again when Valhalla step 1 lands, i think it's better to stick with a more general rule that say that you can have a case with a constant with a case with a type pattern (or a guard that starts with that type pattern) if the type of the constant is a subtype of the type of the type pattern. This will work with case null, Integer i: case "foo", String s && ...: and will not allow case null, APrimitiveClass apc: in the future. > > > So the first rule forbids you from writing case 42, Integer i. The second rule > allows you to say case null, Integer i (and case Integer i, null actually.) > > So, yes, the null is treated specially. Indeed it?s behaviour is NOT about fall > through really. When you write case null, Foo f you are not asking for the type > pattern test to be carried out if the value is null (it might fail!). Nor are > you asking for it to be ignored (cos then the pattern variable will not be > initialised). You?re actually saying ?if it?s null then it matches AND the > variable i is initialised to null?. So it?s being treated like a special > pattern label. If we were to give it an alternative syntax, we might write > ?case Foo? f? instead of ?case null, Foo f?. > > Hope this helps, > > Gavin regards, R?mi > > >> Then i wonder if this special behavior is special because null is special or if >> it should work with any values of the type of the type pattern, >> i.e. it works because null is a possible value of Integer, in that case, it >> should also work with any other values like 42 >> >> case 42, case Integer i -> // i can use 'i' here >> >> So is null a special value or does this rule also work with any values. >> >> regards, >> R?mi >> From james.laskey at oracle.com Thu Sep 16 13:28:41 2021 From: james.laskey at oracle.com (Jim Laskey) Date: Thu, 16 Sep 2021 13:28:41 +0000 Subject: String Tapas Redux: Beyond mere string interpolation Message-ID: Amber experts, Now that JDK 17 has been plated and left the kitchen, we should have a look-see at one of the new menu items Brian and I have had on a slow boil for these last few months; Templated Strings. Before you start shouting out, "Templated Strings? This isn't what I ordered! The subject said string interpolation!!!", take the time to follow this link https://github.com/openjdk/amber-docs/tree/master/site/design-notes/templated-strings.md. After reading, we hope you'll see that the offering is much better than interpolation meat and potatoes. Cheers, -- Jim From forax at univ-mlv.fr Fri Sep 17 00:10:16 2021 From: forax at univ-mlv.fr (Remi Forax) Date: Fri, 17 Sep 2021 02:10:16 +0200 (CEST) Subject: String Tapas Redux: Beyond mere string interpolation In-Reply-To: References: Message-ID: <1691075592.2270344.1631837416140.JavaMail.zimbra@u-pem.fr> Brian explicitly ask me to not talk about invokedynamic so i will not say that there is already an existing protocol between invokedynamic and a user defined implementation, it's the bootstrap method, Let's talk about the elephant in the room: macro. Templated Strings as currently defined is indiscernible from a hygienic String based macro system [1]. Using javac as an API (like jshell does), it seems trivial to come with something like EVAL."\(a) + \(b)" being able to evaluate at runtime any Java expressions. I'm not sure if it's a good thing or a bad thing. R?mi [1] https://en.wikipedia.org/wiki/Hygienic_macro > From: "Jim Laskey" > To: "amber-spec-experts" > Sent: Jeudi 16 Septembre 2021 15:28:41 > Subject: String Tapas Redux: Beyond mere string interpolation > Amber experts, > Now that JDK 17 has been plated and left the kitchen, we should have a look-see > at one of the new menu items Brian and I have had on a slow boil for these last > few months; Templated Strings. > Before you start shouting out, "Templated Strings? This isn't what I ordered! > The subject said string interpolation!!!", take the time to follow this link [ > https://github.com/openjdk/amber-docs/tree/master/site/design-notes/templated-strings.md > | > https://github.com/openjdk/amber-docs/tree/master/site/design-notes/templated-strings.md > ] . After reading, we hope you'll see that the offering is much better than > interpolation meat and potatoes. > Cheers, > -- Jim From brian.goetz at oracle.com Fri Sep 17 00:22:11 2021 From: brian.goetz at oracle.com (Brian Goetz) Date: Thu, 16 Sep 2021 20:22:11 -0400 Subject: String Tapas Redux: Beyond mere string interpolation In-Reply-To: <1691075592.2270344.1631837416140.JavaMail.zimbra@u-pem.fr> References: <1691075592.2270344.1631837416140.JavaMail.zimbra@u-pem.fr> Message-ID: While I get where you're coming from, I don't think that part is anything new or scary. This is isomorphic to methods like: ??? static Foo EVAL(String script, Object... params) { ... } The slightly more convenient syntax may seem attractive at first, but ultimately, it's not really all that different from the EVAL method above; the difference between ??? EVAL."Foo \{foo} Bar \{bar}" and ??? EVAL("Foo {} Bar {}", foo, bar) is not the difference between "macros" and "no macros". I am sure we'll see interesting abuses, but that's not the point. So, what is the point?? The point is that string interpolation is one of the most commonly requested features, and we'd make a lot of people happy if we did it.? While it's a harmless-seeming feature in theory, we're unwilling to do the weak version of string interpolation that most other languages have satisfied themselves with (we can justify this unwillingness solely on the SQL injection risk, but there are other reasons.)? So if we want to make all those people happy, we have to do a version that is smart enough to address the obvious security hazards. This proposal seems to me about as close as we're going to get to making the people happy while addressing the required constraints, without doing something totally crazy. On 9/16/2021 8:10 PM, Remi Forax wrote: > Brian explicitly ask me to not talk about invokedynamic so i will not > say that there is already an existing protocol between invokedynamic > and a user defined implementation, it's the bootstrap method, > > Let's talk about the elephant in the room: macro. > Templated Strings as currently defined is indiscernible from a > hygienic String based macro system [1]. > > Using javac as an API (like jshell does), it seems trivial to come > with something like EVAL."\(a) + \(b)" being able to evaluate at > runtime any Java expressions. > > I'm not sure if it's a good thing or a bad thing. > > R?mi > > [1] https://en.wikipedia.org/wiki/Hygienic_macro > > > ------------------------------------------------------------------------ > > *From: *"Jim Laskey" > *To: *"amber-spec-experts" > *Sent: *Jeudi 16 Septembre 2021 15:28:41 > *Subject: *String Tapas Redux: Beyond mere string interpolation > > Amber experts, > > Now that JDK 17 has been plated and left the kitchen, we should > have a look-see at one of the new menu items Brian and I have had > on a slow boil for these last few months; Templated Strings. > > Before you start shouting out, "Templated Strings? This isn't what > I ordered! The subject said string interpolation!!!", take the > time to follow this link > https://github.com/openjdk/amber-docs/tree/master/site/design-notes/templated-strings.md > . > After reading, we hope you'll see that the offering is much better > than interpolation meat and potatoes. > > Cheers, > > -- Jim > From amaembo at gmail.com Fri Sep 17 02:35:08 2021 From: amaembo at gmail.com (Tagir Valeev) Date: Fri, 17 Sep 2021 09:35:08 +0700 Subject: String Tapas Redux: Beyond mere string interpolation In-Reply-To: References: Message-ID: Hello! Just read the proposal. I don't have any useful comments for now. For me, the proposal looks great as is. Go ahead and implement it :D With best regards, Tagir Valeev. On Thu, Sep 16, 2021 at 8:28 PM Jim Laskey wrote: > > Amber experts, > > Now that JDK 17 has been plated and left the kitchen, we should have a look-see at one of the new menu items Brian and I have had on a slow boil for these last few months; Templated Strings. > > Before you start shouting out, "Templated Strings? This isn't what I ordered! The subject said string interpolation!!!", take the time to follow this link https://github.com/openjdk/amber-docs/tree/master/site/design-notes/templated-strings.md. After reading, we hope you'll see that the offering is much better than interpolation meat and potatoes. > > Cheers, > > -- Jim From john.r.rose at oracle.com Fri Sep 17 06:43:29 2021 From: john.r.rose at oracle.com (John Rose) Date: Fri, 17 Sep 2021 06:43:29 +0000 Subject: String Tapas Redux: Beyond mere string interpolation In-Reply-To: References: Message-ID: Yay! I agree with Brian?s response to Remi: Nothing new here regarding eval or ASTs. My favorite wished-for-use-case for templated strings is a grammar where the ?holes? are grammar actions or other configuration points for rules. This paper made me envious for the sake of Java, and also made me think, ?when we get string templates we can try our own shenanigans?: http://www.inf.puc-rio.br/~roberto/lpeg/#grammar http://www.inf.puc-rio.br/~roberto/docs/peg.pdf > We can meet our diverse goals by separating mechanism from > policy. How we introduce parameters into string expressions is > mechanism; how we combine the parameters and the string into a final > result (e.g., concatenation) is policy. One might also say we separate wiring from function. How we introduce a segmented string with holes, and also (typed) expressions to fill those holes, is the wiring. (No function yet: We just observe all those values waiting for us to do something with them.) How we arrange the static structure of those values verges on function, but it?s really just setting up for the moment when we have all the values and can run our function. The function comes in when we have all the values (crucially, the dynamic and typed hole-filling values). At that point it?s really ?only? a method call, but that method contains all the function (the ?policy?). The intermediate step where we derive a recipient for the function call, from the static parts (strings, and also hole types), is a factory method or constructor call, one which creates the receiver object (which is constant for that expression, just like a no-capture lambda). It?s important to separate wiring from function in part because (a) wiring can be fully understood while (b) function is inherently undecidable. So it?s good (for extensibility, universality) when the wiring is really simple and clear, and the transitions into the mysterious function-boxes are also really clear. Also, if we focus on wiring that is as universal as possible, we can do fancy stuff like grammars with functional actions. Otherwise, it?s harder. Also, making the function part ?only a method call? means that whatever resources the language has to make method calls be a good notation apply to templated strings. Also, since the ?wiring part? includes the round-up of the static parts of the template expression, it follows that we can do lots of interesting ?compile time? work in the indy or condy instruction that implements the expression as a whole. I am gently insisting that the types of the ?holes? are part of the template setup code because, after all, that?s what the indy needs anyway, and it seems a shame to make them all be erased to Object and Object[]. One reason ?just use Object? is a missed opportunity: You get lots of boxing. Another, deeper one: Without FI-based target typing that would be provided by a general Java method call, you can?t put poly-expressions (like lambdas) into the holes. For example, a PEG template might take a varargs argument of type (PEGRuleAction? actions) where PEGRuleAction is a FI. (Mixing FIs and other data is a challenge I will delay for now, but it?s under the rubric of ?Varargs 2.0?, allowing methods to capture variable-length yet type-heterogeneous arguments. Think also for Map.of(?) which wants to take pairs of arguments of alternating types. But that?s for later.) I?m fully aware that I will be asking for stuff that is beyond a 1.0-level feature set, but in discussing stuff like this I?m hoping to stake out a path for growth to wider set of use cases that inevitably comes if the meaning of the expression is ?call this method on this compute-once receiver?, as opposed to something more constrained (even if the 1.0 level is constrained). Or, to go back to the ?mechanism vs. policy? formulation, the (very interesting) policy is embodied in the template expression receiver object itself that is built on first use of the expression, and it is also in the (very interesting) method that is called on the object with the typed hole values. The mechanism consists of the rules by which the expression receiver object (TemplatePolicy) is created, and what values are passed to its constructor or factory (just once, lazy), and then (each time the expression is evaluated) how the holes are passed to the object, and via which method. The wiring I?m suggesting starts with a one-time setup operation, which needs to be statically defined (no dynamic argument dependencies). I?m suggesting that the policy provides a factory method which is run once (probably via a condy or indy) per expression. I will use really, really dumb names for the two interfaces that characterize the processing at the two phases, the one-time setup and the each-time evaluation of the template. interface TemplatePolicyPhase1> { P2 setup(List parts, MethodType type); // type takes all the hole arguments and returns S } Note that TemplatePolicyPhase1 is a FI. It is a factory run at expression-link time, and it makes a phase 2 thingy which knows how to execute the expression: interface TemplatePolicyPhase2 { List parts(); //?MethodType type(); S execute(Object? args); } or, maybe better with MHs (with a workaround to invokeWA for arity limits): interface TemplatePolicyPhase2 { List parts(); MethodHandle executor(); default MethodType type() { return executor().type().dropParameterTypes(0,1); } default S execute(Object? args) { return executor().bindTo(this).invokeWithArguments(args); } } The names are deliberately dumb here. The latter one (with the MH) is preferable, because (a) it can reflectively report its exact type and (b) the javac compiler can use the MH to pass the arguments under exactly correct types (not just Object, not varargs). The instance of TemplatePolicyPhase1 is really a witness to a particular policy, as well as a way to execute it. Once you have a TemplatePolicyPhase1 in hand it?s clear how the wiring works and how to set up the indy or condy. public class String { public record SimpleTemplatePolicy(List parts, MethodType type) { implements TemplatePolicyPhase2 { maker() { ?do something here? } } // witness to the policy: public static final TemplatePolicyPhase1 SETUP_TEMPLATE_POLICY = SimpleTemplatePolicy::new; } To bootstrap things, there could be a rule whereby that if a type has a static method or field or nested class of appropriate name and type, the construction method (or other witness value) is wired to the position of the TemplatePolicyPhase1. That method can be called from a condy or indy, the first time the expression is executed. That means the inference finds one TemplatePolicyPhase1 witness per type. Eventually we can enhance this further if we want to define a special kind of ?static constant? expression that can provide (as if through a lazy static variable) a computed constant of some sort. Maybe String or SQLQuery can have several named witnesses available: SQLQuery.NORMAL.?template ??. I think there is a place somewhere in the language for lazy statics, which could provide named access points for such ?witnesses?, as well as do many other jobs. If the phase 2 protocol uses method handles, then we desugar to something like this: // int n; Object w; // var s = String.?hello, \{n} times to you, \{w}?; lazy @Condy static final MethodType MT42 = methodType(String.class, /*n*/ int.class, /*w*/ Object.class); lazy @Condy static final List SL42 = Utils.splitForST(?hello, \0 times to you, \0?); lazy @Condy static final TemplatePolicyPhase1 TP43 = String.SETUP_TEMPLATE_POLICY.setup(SL42, MT42)); lazy @Condy static final MethodHandle MH44 = TP43.maker(); var s = (String) MH44.invokeExact(TP43, n, w); In this desugaring, perhaps in some cases javac can decide on some M and call TP43.M(n,w) instead of materializing the MH44, which might as well be (in most cases) just a wrapper around M. A universal ?all wires exposed? policy-free policy might look like this: public record BasicTemplate (TemplatePolicyPhase2 policy, List