Quick question regarding pattern matching
Brian Goetz
brian.goetz at oracle.com
Thu Mar 23 14:32:16 UTC 2017
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
More information about the amber-dev
mailing list