New pattern matching doc

[forax at univ-mlv.fr]

> De: "Brian Goetz" <brian.goetz at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "amber-spec-experts" <amber-spec-experts at openjdk.java.net>
> Envoyé: Vendredi 8 Janvier 2021 17:05:06
> Objet: Re: New pattern matching doc

>> By example, case Optional.of() is called the static pattern in the document, but
>> the corresponding member is not static at al, it has to have access to the
>> values of the instance.

> This is not correct. The pattern `Optional.of()` is truly static.
The pattern is static, but perhaps not as "static" in a static method call, but as "static" in a method reference way. 
For Optional.of(var x), the implementation needs to take a look to the content of the Optional, thus the implementation is not static as in static method. 
For Integer.parseInt(int value), this is not a instance method of String but a static method inside Integer that either binds an int or does not match. 

>> I've proposed to call the patterns "patterns" and the corresponding class member
>> "case methods" for that reason, you may prefer other names, but i think that
>> making this separation is important.

> Maybe. (Or maybe it's actively unhelpful, because you don't quite get the model
> yet -- so let's make sure you understand the model fully first.)

> Let me step back, and draw some connections between methods/ctors and patterns.
> We currently have three kinds of executable members: ctor, static methods,
> instance methods.

> - Constructors have a receiver, are not inherited, and do not have names.
> (Really, they don't; the class name is just a surface syntax artifact, it could
> just as easily have been "new" or "constructor" (and is erased to <init> in the
> classfile). When you say `new ClassName(args)`, the identifier `ClassName` is
> the name of a class, not a constructor.)

> - Static methods have no receiver, are not inherited, and have names.

> - Instance methods have a receiver and are inherited, and have names.

> All patterns are "invoked" only through pattern matching (and perhaps through
> reflection), not directly. There are many kinds of patterns, and names in
> patterns go through various processes to map them to patterns.

> case Foo f: // type pattern
> case Foo(int x): // deconstruction pattern
> case Foo.of(var x): // static pattern
> case withMustard(var amount): // instance pattern

> For `case Foo f`, this is a type pattern, and the `Foo` class is uninvolved. The
> applicability test is just classic `instanceof`.
yes ! 

> For `case Foo(int x)`, this is a deconstruction pattern, and Foo is the name of
> a class, not of a pattern. Just like with constructors, we look in class Foo
> (not superclasses) for a matching deconstructor. The target becomes the
> receiver of the pattern invocation.
The application test is an instanceof + a call to the deconstructor which as a special linking semantics for transferring the bindings 

> For `case Foo.of(var x)`, this is a static pattern. Foo is the name of a class,
> and `of` is the name of a declared static pattern in Foo. The target becomes an
> argument of the pattern invocation.
The application test is an instanceof + a call to the method an instance method of() with, i hope, the same special semantics for transferring the bindings. 
Unlike the deconstructor, this instance method can be overridden (you want to be able to declare such method on an interface). 

> For `case withMustard(var amount)`, this is an instance pattern. We look in the
> static type of `Foo` for an instance pattern called `withMustard`. The target
> becomes the receiver of the pattern invocation.
As Tagir said, we may want to abbreviate a static pattern like Foo.of(var x) to of(var x) is the declared type of the switch is Foo. 
So i think it's prematured to see this pattern as another kind of pattern and not just as a . 

> Possibly orthogonally, some patterns are total on their target type, and some
> are not. Totality is used in switches, and also in pattern-bind statements; if
> we have a pattern bind

> Point(var x, var y) = p

> then the pattern used here must be total on the static type of `p`.

> We could choose a model where all patterns had a `total` or `partial` modifier,
> but after writing a bunch of code, it became clear that the vast majority of
> deconstruction patterns are total, and the vast majority of others are partial,
> and so it is a simplifying move to "lump" and say "deconstruction patterns are
> always total; other patterns are always partial." (This is a contingent choice,
> and could be revisited later, once we write a lot more code.)
I agree that the deconstruction pattern should always be total otherwise we will cases where o instanceof Point is true but o instanceof Point(var x, var y) is false. 

> I think you're saying "we should treat deconstruction patterns as a special case
> of static patterns." Not sure why you think that, maybe that "having fewer
> kinds of patterns is simpler?" (If so, I think it's not simpler -- I think its
> simpler to have a pattern that is dual to constructor and structurally like
> constructors, and a static pattern that is dual to static factories and
> structurally like static factories.) Constructors and static factories are
> different; one has a receiver, one does not; one has a name, one does not.
It's more that i want that all patterns that have bindings to share the same meta-protocol (the way to bind bindings). 
You are right that the deconstructor (the method declared in the class) should not be inherited, may have some delegation restrictions, and is total (can not return a boolean) like a constructor. 
But a constructor neither need a special keyword nor have a semantics different from a classical methods, likewise a deconstructor and a method called by a static pattern should share the same semantics to bind the bindings. 

> Does this help?

Does it help ? 

Rémi 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20210111/34d77eea/attachment.htm>