> From: "John Rose" <john.r.r...@oracle.com> > To: "Brian Goetz" <brian.go...@oracle.com> > Cc: "Remi Forax" <fo...@univ-mlv.fr>, "Jesper Steen Møller" > <jes...@selskabet.org>, "Ilyas Selimov" <ilyas.seli...@jetbrains.com>, > "amber-spec-experts" <amber-spec-experts@openjdk.java.net> > 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.r...@oracle.com | >> john.r.r...@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
