A peek at the roadmap for pattern matching and more

[forax at univ-mlv.fr]

----- Mail original -----
> De: "John Rose" <john.r.rose at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "Brian Goetz" <brian.goetz at oracle.com>, "amber-spec-experts" <amber-spec-experts at openjdk.java.net>
> Envoyé: Jeudi 13 Août 2020 01:36:41
> Objet: Re: A peek at the roadmap for pattern matching and more

> On Aug 12, 2020, at 4:28 PM, Remi Forax <forax at univ-mlv.fr> wrote:
>> 
>> 
>> I know that you have consider something like this, but i prefer making the
>> deconstructor a method returning a tuple at Java level, to be closer to the JVM
>> level.
>> So a syntax more like
>>   class Point {
>>     int x;
>>     int y;
>> 
>>     (int x, int y) deconstructor {
>>       return (this.x, this.y);
>>     }
>>   }
>> 
>> Conceptually, it's also more like the reverse of a constructor, a constructor
>> takes the values from the stack to move them to the heap, a desconstructor
>> takes the value from the heap and move them to the stack.
> 
> To be closer to the JVM level we should number our variables, not name them.
> That is, if being closer to the JVM level were so important as to prefer
> positional notations to name-based notations.

I was thinking about closer to the generated classfile, not closer to the VM internals.

> 
> One reason to avoid tuples is we’d have to reify them more thoroughly in the
> language, and that seems like busy-work.

It depends if tuples are reified by the VM or not.

> 
> The more important reason to avoid tuples is they don’t have named components,
> and the stuff we are looking at these days with records, constructors, and
> deconstructors is *all about names*.

yes, a tuple as a type is a structural type, if we use the now classical move of using a nominal type + some inference rules to represent the type of a tuple,
the record class is a tuple type, so yes it has names the same way an abstract method of a functional interface has a name.

> 
> — John

Rémi