Quick question regarding pattern matching

[Brian Goetz]

Without getting into the details -- I'd like to wait until a Patterns 
JEP is proposed before doing so -- I'll give some quick overview answers.

1.  Yes, exhaustiveness is important.  The obvious tool there is 
sealing, and sealed classes at the language level would really also like 
sealing support at the VM level, which can be considered a 
generalization of finality.  (Though, even with sealing at both the 
language and VM level, there is still a possibility of being surprised 
by separate compilation artifacts, since if the switch is in a different 
class than the one in which the supposedly-sealed hierarchy is defined, 
new subtypes can still be added, and if the client is not recompiled, 
you will get a surprise.)  Stay tuned.

2.  We try :)  There are likely to be VM-level building blocks that 
multiple languages can build on, and sealing is a good example.  That 
said, any given VM feature isn't always ideal for every language.  The 
balance we try to strike is: try to identify the right VM primitives 
that are useful to as broad a selection of languages as possible -- but 
don't get caught up in trying to design a grand unified theory, as 
that's not the primary goal. (Default methods are a good example; 
they're useful to a lot of languages, but some languages may choose not 
to use them as a trait substrate because they want different conflict 
resolution semantics.  And that's OK.)

On 3/23/2017 9:32 AM, org.openjdk at io7m.com wrote:
> Hello!
>
> I thoroughly enjoyed Brian's talk that was linked to from the original
> Amber introduction email. I'm very surprised and happy to learn that
> full pattern matching is under consideration as an addition to the
> language (I was expecting to only get case analysis as that's somewhat
> cheaper and easier to implement).
>
> Couple of small questions:
>
> 1. The talk makes no mention of checking matches for exhaustiveness. Is
>     that just an omission from the talk for brevity? For me, the main
>     value in pattern matching is the exhaustiveness checks [0].
>
> 2. Is the intention of Amber to include some sort of VM-level
>     infrastructure to allow for languages that implement algebraic data
>     types to share a common model? For example, if I declare an algebraic
>     data type in Kotlin, it would be really nice if I could then pattern
>     match on it in Java or Scala and get the same exhaustiveness checks.
>     Right now that's obviously not going to happen as they each use a
>     slightly different representation for ADTs. For example, I believe
>     the Kotlin compiler adds some protobuf-encoded data to each
>     compiled ADT class as annotations to mark the class as "sealed".
>     Users can later get exhaustiveness checks when matching on a value
>     of that class because the compiler can infer that the class is sealed
>     from the annotations. A Scala compiler looking at a type compiled by
>     the Kotlin compiler obviously isn't going to read and/or understand
>     those annotations.
>
> Regards,
> Mark
>
> [0] https://www.youtube.com/watch?v=DM2hEBwEWPc