Updated pattern match documents

[Jean-Baptiste Giraudeau]

Hi Brian,

As a scala user this looks very familiar. From a functional programmer
point-of-view, there is a few topics that I'd very much like to see
mentioned, even every shortly.

1. tail call optimizations: as pattern matching is very often associated
with recursion it would be nice to mention any plan about it being
supported one day (or not).

2. type casing / casting on a universally quantified type variables:
this breaks parametricity, so functional programmers would want to avoid
it. As I understand, in such case a default branch is required, correct?
It would then be a nice improvement over scala, which does not emit a
warning on non-exhaustive matches in such cases.
Requiring `default` means that a functional programmer can be sure that
their pattern match is "legal" (ie. only on ADT) as long as `default` is
never used. The best would a compiler flag that would only allows
structural decomposition on sealed/enum... but this is probably asking
too much...?

3. Support of GADT. Is there any plan to support unification in GADT
structural decomposition? ie. would the following code be compilable,
one day:

sealed interface Term<T>{}
record Zero() implements Term<Integer>;
record Succ(Term<Integer> pred) implements Term<Integer>;
record Pred(Term<Integer> succ) implements Term<Integer>;
record IsZero(Term<Integer> i) implements Term<Boolean>;
record If<T>(Term<Boolean> cond, Term<T> then, Term<T> otherwise)
implements Term<T>;


    static <T> T eval(Term<T> term) {
        return switch (term) {
            case Zero() -> 0;
            case Succ(var pred) -> eval(pred) + 1;
            case Pred(var succ) -> eval(succ) - 1;
            case IsZero(var t) -> eval(t) ==0;
            case If(var cond, var then, var otherwise) -> eval(cond) ?
eval(then) : eval(otherwise)
        }
    }


cheers,

-
jb

On 9/7/18 8:41 PM, Brian Goetz wrote:
> I've updated the documents regarding pattern matching, and uploaded
> them here:
>
> http://cr.openjdk.java.net/~briangoetz/amber/pattern-match.html
> http://cr.openjdk.java.net/~briangoetz/amber/pattern-semantics.html
>
> The first document is an update of a previous document (old version
> available here:
> http://cr.openjdk.java.net/~briangoetz/amber/pattern-match_1.html),
> and outlines the general arc of the feature and general motivation.
>
> The second captures the discussions we've had regarding the messy
> details of typing, scoping, nullability, shadowing, etc.  I think
> we've made a lot of progress on these.
>
> We would not implement this all at once; we'd proceed incrementally,
> probably starting with type patterns in `instanceof`, and then
> proceeding to `switch` or to deconstruction patterns.
>
> Please review and comment.
>