Published: pattern matching

[Remi Forax]

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.

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) ?

- 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 ?

- 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.