Member Patterns -- the bikeshed

[Guy Steele]

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.

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

—Guy

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-spec-experts/attachments/20240404/cbace7e9/attachment-0001.htm>