> 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.
> 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" <[email protected]>
>> À: [email protected]
>> 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.
