[pattern-switch] Totality

[forax at univ-mlv.fr]

----- Mail original -----
> De: "Brian Goetz" <brian.goetz at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "Guy Steele" <guy.steele at oracle.com>, "amber-spec-experts" <amber-spec-experts at openjdk.java.net>
> Envoyé: Dimanche 30 Août 2020 16:23:38
> Objet: Re: [pattern-switch] Totality

> Yes, this looks very much like a PoC I did once too.  The upshot of that
> experiment is that operators like AND, OR, nesting, and guarding are amenable
> to implementation as combinators, which is nice.
> 
>> To deal with the deconstruction, i need 3 primitives
>> - deconstruct(Object value) that calls the deconstructor if the deconstructed
>> object is a class
> 
> Here you’re making an assumption about the language model, which is that classes
> may only have one deconstructor.  This is a pretty serious limitation, and
> forces pattern matching to stay very much on the periphery of the object model.
> (I know why you want to make this assumption, because you want the bindings to
> be the return type and there is no return type overloading.)

It's a PoC.

You can notice that adding more fields to the anonymous record, the record returned by the destructor is a binary compatible change.
It can also be a source compatible change if the compiler allows the deconstructing pattern to have less parameters than the declared parameters of the deconstructor.
By example, for a record Pixel(int x, int y, String color) {},
i.e if instead of the pattern Pixel(var x, var y, var _), one can write the pattern Pixel(var x, var y).

You can also select among several deconstructors at runtime (as a linking pass done once) if they return a disjoint set of values,
by first selecting all the applicable deconstructors and then selecting the most specific when you construct the method handle tree.
But i'm not sure you need that dynamic linking selection in practice.


>> - extract(Record record, String name) that can extract the value of a record
>> component from its name
>> - with(Record record, String name, Object value) that creates a new record with
>> the value of the record component corresponding to the name changed
>> 
>> The implementation of those primitives relies on the reflection so it's slow and
>> wrong in term of security, but it's enough for a prototype [2]
> 
> Yes, but.  It also makes an assumption about runtime resolution of bindings
> based on component name.  Again, you are making a big assumption about “how the
> language should work”, but again it has gotten buried in an implementation
> detail.  So whatever we learn from this model comes attached to some big
> assumptions.

The assumption is that
  case Pixel(_ , _, var color) -> System.out.println(color);
is equivalent to
  if (value instanceof Pixel pixel) {
    var record = pixel.deconstructor();  // if Pixel is not a record
    System.out.println(record.color());
  }

>From a user POV you don't care, from a binary compatible POV, there is no explicit reference to a specific deconstructor in the bytecode because the matching is done by name instead of being positional.

> 
> FWIW, my implementation treated a pattern as a bundle of method handles, one was
> a mapping from the match target to an opaque carrier (null meant no match), and
> N method handles from the carrier to the binding value.  In many cases the
> target itself was a suitable carrier.

a real implementation should not use null because we want the carrier object to be an inline, but saying by convention that if __index__ == 0 (which is equivalent to saying it's the default value of an inline) represents "not match" should be enough.  

> 
>> The deconstruction is based on the names of the record components and not their
>> declared positions in the record.
>> You may think that this way of doing the deconstruction is not typesafe but the
>> fact that all the fields of the carrier record are typed means that all the
>> bound variables have the correct type.
> 
> Yes, but type safety is one of the lesser of my concerns here.
s t
ok, good.

Rémi