Published: pattern matching
forax at univ-mlv.fr
forax at univ-mlv.fr
Wed Apr 19 15:08:47 UTC 2017
----- 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
More information about the amber-spec-experts
mailing list