Published: pattern matching

[forax at univ-mlv.fr]

----- Mail original -----
> De: "Gavin Bierman" <gavin.bierman at oracle.com>
> À: "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>
> Envoyé: Mercredi 19 Avril 2017 16:33:14
> Objet: Re: Published: pattern matching

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

from my own experience, i've added new features in the language when i see how easy it was to implement them when i had the first cut of the implementation.

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

yes,
local of the surrounding context can only be used in the action but not in the pattern ?

and guards are ugly, people write code like this:
  case A(Long(Long(Complicated(Pattern(var x))))) where x == n -> action1()
  case A(Long(Long(Complicated(Pattern(var x))))) where x != n -> action2()

instead of
  case A(Long(Long(Complicated(Pattern(var x))))) -> x == n? action1(): action2()

> 
> 
> Gavin

Rémi