[External] : Re: Proposal: java.lang.runtime.Carrier

[forax at univ-mlv.fr]

> From: "Brian Goetz" <brian.goetz at oracle.com>
> To: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "John Rose" <john.r.rose at oracle.com>, "Jim Laskey"
> <james.laskey at oracle.com>, "amber-spec-experts"
> <amber-spec-experts at 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 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20220309/16fbec21/attachment.htm>