Collections patterns

[forax at univ-mlv.fr]

> From: "Brian Goetz" <brian.goetz at oracle.com>
> To: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "amber-spec-experts" <amber-spec-experts at openjdk.java.net>
> Sent: Wednesday, May 18, 2022 11:08:41 PM
> Subject: Re: Pattern matching: next steps after JEP 405

>> Inference is also something we will need for pattern assignment

>> Box<>(var s) = box;

> Yes, it would work the same in all pattern contexts -- instanceof as well. Every
> pattern context has a match target whose static type is known.

>>> - Array patterns. The semantics of array patterns are a pretty simple extension
>>> to that of record patterns; the rules for exhaustiveness, applicability,
>>> nesting, etc, are a relatively light transformation of the corresponding rules
>>> for record patterns. The only new wrinkle is the ability to say "exactly N
>>> elements" or "N or more elements".
>> I wonder if we should not at least work a little on patterns on collections,
>> just to be sure that the syntax and semantics of the patterns on collections
>> and patterns on arrays are not too dissimilar.

> This is a big new area; collection patterns would have to be co-designed with
> collection literals, and both almost surely depend on some sort of type class
> mechanism if we want to avoid the feature being lame. I don't think its
> realistic to wait this long, nor am I aiming at doing anything that looks like
> a generic array query mechanism. Arrays have a first element, a second element,
> etc; the nesting semantics are very straightforward, and the only real question
> that needs additional support seems to be "match exactly N" or "match first N".
We may want to extract sub-parts of the array / collections by example, and i would prefer to have the same semantics and a similar syntax. 

And i don't think we need type classes here because we can use the target class mechanism instead, like we have done with lambdas, 
instead of Type x -> x + 1 or whatever the exact syntax, we have (Type) x -> x + 1 

We may want [1, 2, 3] to have a type, so it's maybe a little more complicated than just using the target typing but i don't think type classes are needed for collection litterals. 
For operator overloading on numeric value classes, that's another story. 

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