Member Patterns -- the bikeshed

[forax at univ-mlv.fr]

> From: "Guy Steele" <guy.steele at oracle.com>
> To: "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>
> Sent: Thursday, April 4, 2024 5:04:30 PM
> Subject: Re: Member Patterns -- the bikeshed

>> On Apr 4, 2024, at 9:30 AM, forax at univ-mlv.fr wrote:

>> Patterns are not dual of methods, pattern deconstructors are dual of methods,
>> but this is a special case.

>> A pattern not only have a sequence of match results, it can have parameters too.
>> For example, I may want to introduce an instance pattern asInteger() in
>> java.lang.String that works like Integer.parseInt() but not match instead of
>> throwing an exception if the string does not represent an integer. I may also
>> want that pattern to decode hexadecimal so like Integer.parsing(int radix), I
>> want my pattern to also takes a radix as parameter. In that case, my pattern
>> asInteger() has an int value as match result and has an int radix as parameter.

>> Using the carrier syntax, it's something like
>> carrier(int value) asInteger(int radix) { ... }

>> or without the carrier syntax but with a keyword pattern, it's something like
>> pattern (int value) asInteger(int radix) { … }

> I think what is missing is a necessary shift in terminology under Brian’s new
> proposal: if parameters are needed for a pattern, then in effect you curry it.
> In this new model, `asInteger` is not a pattern; rather, it is a pattern
> factory—that is, a method that returns a pattern. This is possible because of
> the introduction of SAPs, so that a pattern can be expressed using lambda
> syntax.

This is super confusing. 
For curryfication, you need at least one parameter, so the SAP needs have one parameter but at the same time a SAP abstracts a pattern and pattern can not have a parameter ? 

> So we should speak of method `asInteger` as a pattern factory, and
> `asInteger(16)` as a pattern.

You mean, asInteger().apply(16) or SAP unlike SAM can to be called directly using parenthesis ? 

You also 
- loose the ability to have several overloads, asInteger() and asInteger(16) can not be both valid at the same time if you have currification (at least in Java). 
- you need a new way to distinguish between a pattern and a pattern factory, the former has bindings, the later return a SAP interface. 

So we have a small/medium feature "pattern method" but for some reasons I do not understand instead of being a special kind of method, it's an entirely new concept, pattern. 
The body of a pattern works like a body of a method but for some reasons i do not undesrtand for returning the binding values, you have to use the name of the pattern (apart if this is a single abstract pattern because in that can it's the interface) and for returning no match, this is implicit. Some existing languages work like that but not Java. 
The parameters of a pattern instead of being method parameters, for some reasons i do not understand uses curryfication. Some languages work like that but not Java. 

This is very confusing. 
Again, why a pattern is not a new kind of method with a binding list instead of a return type and in the body, one can return match(val1, val2, ...) or return nomatch ? 

> —Guy

Rémi 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-spec-observers/attachments/20240408/4dcc95c7/attachment.htm>