From jb at giraudeau.info  Fri Sep  7 20:12:08 2018
From: jb at giraudeau.info (Jean-Baptiste Giraudeau)
Date: Fri, 7 Sep 2018 22:12:08 +0200
Subject: Updated pattern match documents
In-Reply-To: <cfca73ab-0fb6-056e-ef05-bdcab3d9b4f0@oracle.com>
References: <cfca73ab-0fb6-056e-ef05-bdcab3d9b4f0@oracle.com>
Message-ID: <8c2c5c61-0170-3054-4f4a-6ba714faf831@giraudeau.info>

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.
>

From lukas.eder at gmail.com  Wed Sep 19 20:44:04 2018
From: lukas.eder at gmail.com (Lukas Eder)
Date: Wed, 19 Sep 2018 22:44:04 +0200
Subject: JEP draft: Concise Method Bodies - extend this to local functions?
Message-ID: <CAB4ELO6B5qKLXnqb_wLCj3Cb8b7oNc1AtzfmpYnXA2msBf3R9g@mail.gmail.com>

Hello,

I've just seen this new JEP draft, which really looks very useful:
http://openjdk.java.net/jeps/8209434

Now, given that this would be possible:

    int x(String s) -> s.length();

And given that this almost looks like a named lambda expression, could this
maybe be an occasion to re-discuss the possibility of supporting named
lambda expression / local functions?

E.g.

    void m() {

        // lambda local to m()
        ToIntFunction<String> x1 = (String s) -> s.length();

        // "method" local to m()
        int x2(String s) -> s.length();

        // We can now do:
        int i1 = x1.apply("abc");

        // More concise
        int i2 = x2("abc");
    }

I know this was discussed for Java 8 and rejected, but given the high
similarity of the currently proposed concise method body syntax and the
lambda syntax, I feel that on a high level, this might appear coherent and
useful.

Of course, in such a case, it would appear useful to allow the original
method body syntax as well in a local method:

    void m() {
        int x3(String s) {
            return s.length();
        }
    }

Also, many other languages have this feature, e.g. Scala, Ceylon, Kotlin

Thanks,
Lukas