> From: "Brian Goetz" <brian.go...@oracle.com> > To: "Remi Forax" <fo...@univ-mlv.fr> > Cc: "John Rose" <john.r.r...@oracle.com>, "Jim Laskey" > <james.las...@oracle.com>, "amber-spec-experts" > <amber-spec-experts@openjdk.java.net> > Sent: Wednesday, March 9, 2022 2:31:33 PM > Subject: Re: [External] : Re: Proposal: java.lang.runtime.Carrier
>> What i was proposing is for switch to cram "not match" and the index of the >> matching case into one int because using -1 seems natural and it will work >> well >> with the tableswitch. > There’s two levels here, and I think part of the confusion with regard to > pattern translation is we’re talking at different levels. yes, > The first level is: I’ve written a deconstructor for class Foo, and I want to > match it with instanceof, case, whatever. I need a way to “invoke” the pattern > and let it conditionally “return” multiple values. Carrier is a good tool for > this job. > The second level is: I want to use indy to choose which branch of a switch to > take, *and* at the same time, carry all the values needed to that branch. > Carrier could be applied to this as well. > Somewhere in between, there’s the question of how we roll up the values in a > compound pattern (e.g., Circle(Point(var x, var y) p, var r) c). This could > involve flattening all the bindings (x, y, p, r, c) into a fresh carrier, or > it > could involve a “carrier of carriers”. There are many degrees of freedom in > the > translation story. > What Jim is proposing here is a runtime for bootstraps to make decomposable > tuples that can be pass across boundaries that agree on a contract. This could > be a simple return-to-caller, or it could rely on sharing the carrier in the > heap between entities that have a shared static typing proof. >> To come back to the carrier API, does it means that the carrier class is >> always >> a nullable value type or does it mean that we need to knob to select between >> a >> primitive type or a value type ? > Probably the carrier can always be a *primitive* class type, and the null can > be > handled separately by boxing from QCarrier$33 to LCarrier$33. All the Carrier > API does is provide a constructor which takes N values and returns a carrier; > at that point, you already know you want a non-null value. Consumers higher up > the food chain can opt into nullity. Also, i wonder if the external Carrier API should have a way to wrap an existing record class to see it as a Carrier, so the destructuring pattern will behave the same way with a record or with the result of a de-constructor. Rémi
