Published: pattern matching

[Gavin Bierman]

> On 19 Apr 2017, at 14:55, Remi Forax <forax at univ-mlv.fr> wrote:
> 
> Thanks Brian,
> nice summary, obviously, i'm more interested by the other side of this document, the dark side, i.e. how to implement the pattern matching.

:-) The current pattern matching prototype is decoupled from the more advanced implementation effort. 


> so i've mostly syntactic comments:
> - I was wondering if matches can be spelled instanceof ?
>  i.e if the Java grammar can be extended to support (foo instanceof String s) ?

Possibly, but as a pattern can be a literal value you’d end up allowing (foo instanceof 42). Or, I suppose we could extend instanceof to permit type patterns only. Seems a little ad-hoc though.

> - the var pattern: i'm sure you have considered removing the 'var'
>  int eval(Node n) {
>      return exprswitch(n) {
>          case IntNode(i) -> i;
>          case NegNode(v) -> -eval(v);
>          ...
>      };
>  }
>  but reject it because
>    - from the compiler perspective, you have to wait the typechecking pass (or a pass just before) to know if a symbol 'v' is a parameter or variable access.
>    - if someone write:
>        return exprswitch(n) {
>          case NegNode(n) -> -eval(n);
>        };
>      n in NegNode(n) is a value and not a variable, which is a nice puzzler.
>    - or it means not supporting constant in patterns.
> 
>  Am i right ?

Kind of. We are still working through exactly what we think nested patterns mean. But what the document suggests is that the pattern has a set of binding variables (maybe call these the pattern variables) that are bound by the process of pattern matching (possibly by an extractor). So it’s reminiscent of a (very) local declaration; so ‘var’ seems like the right syntax.  Also, as you spotted, it makes for less grammar ambiguity. 

I don’t think we plan to support equality patterns as you suggest in the NegNode(n) example (if I’m reading it right). If you want that, then you should use a guard:

case NegNode(var x) where x == n -> ...


Gavin


> 
> - exhaustiveness,
>  if the class is sealed/closed, i think all data class should be declared into the interface
> 
>    sealed interface Node {
>      data class IntNode(int value) { }
>      data class NegNode(Node node) { }
>      ...
>    }
>  It makes more clear the fact that you can not open the interface Node to add a new subtype and you do not need to declare that each subtype implements the sealed class.
> 
>  It also means that the real name of IntNode is now Node.IntNode (so you can remove the Node suffix !), but you mostly don't care because when you use the exprswitch, you're switching over a Node so the compiler can infer the right name the same way the compiler infer the right name of an enum constant.
> 
>  And more or less like Scala, the compiler can add a bunch of static factory methods so instead of new Mode.IntNode(0), one can write Node.IntNode(0), IntNode being the name of a factory method that creates an IntNode.
> 
>  The astute reader in me see that as a sum type for the compiler and an interface for the VM, i.e. even if the VM do not allow other subtypes than the one listed at runtime, the fact that you do not have to have a default branch should be a JIToptimization, in the bytecode or in a corresponding method handle tree, the default branch should still exist. 
> 
> regards,
> Rémi
> 
> ----- Mail original -----
>> De: "Brian Goetz" <brian.goetz at oracle.com>
>> À: amber-dev at openjdk.java.net
>> Envoyé: Mardi 18 Avril 2017 23:34:45
>> Objet: Published: pattern matching
> 
>> I've made public the following document:
>> 
>>    http://cr.openjdk.java.net/~briangoetz/amber/pattern-match.html
>> 
>> which offers an overview of possible directions for pattern matching in
>> Java.  This is an exploratory document and does not constitute a plan
>> for any specific feature in any specific version of the Java Language.
>> Similarly, though it may reference other features under consideration,
>> this is purely for illustrative purposes.  There is no timetable on
>> which these features might appear, if ever.
>> 
>> Over the next few weeks, I'm going to begin, slowly, discussing various
>> aspects of pattern matching on the EG list.