----- Mail original ----- > De: "Gavin Bierman" <[email protected]> > À: "Remi Forax" <[email protected]> > Cc: "Brian Goetz" <[email protected]>, "amber-spec-experts" > <[email protected]> > Envoyé: Mercredi 19 Avril 2017 16:33:14 > Objet: Re: Published: pattern matching
>> On 19 Apr 2017, at 14:55, Remi Forax <[email protected]> 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
