Updated State of the Lambda

[Brian Goetz]

On 12/11/2011 8:19 PM, Yuval Shavit wrote:
> Essentially, yes.

I think this may be asking for function types by another syntax.  (Note 
that if you really hate the one-class-per-file rule, you can use nested 
interfaces like Map.Entry.)  But they have to be real interfaces. 
Otherwise, what do we put in the bytecode signature of sort()?  It has 
to be a real type, and the only types we've got right now are 
primitives, classes, and arrays.

> The lambda dev project does a great job of reducing
> the cost of functional interfaces at the instantiation point  -- which,
> don't get me wrong, is a really great thing and no small improvement.
> But the proposal doesn't do much as far as making it easier at the
> declaration point.

Fair enough, but in my book, that's winning.  Anything that moves work 
from library consumers to library producers makes things better for the 
community as a whole.  Libraries are used more often than they are 
written.  And, the library developers can take it.  As a library 
maintainer, I'm willing to have some work shifted to me if it means my 
users can write better code.  That's why we write libraries!

> Framed in terms of inheritance-vs-composition,
> inheritance is still more convenient (albeit marginally) for the API
> designer. If lambdas take off, we'll have an explosion of
> pretty-much-identical functional interfaces.

The plan is to include a basic set of interfaces in java.util.functions. 
  Currently that includes Predicate, Mapper, Operator, and a few others. 
  The exact set is still churning pretty violently, but you can peek at 
the lambda hg repo to see what's there this week.

For existing libraries that already have their own, they can be 
retrofitted to extend the official types.  Let's say j.u.f.Predicate 
looks like this:

interface Predicate<T> {
     public boolean eval(T t);
}

and FooBar Commons has a type

interface Filter<T> {
     public boolean isOK(T t);
}

It can be retrofitted as follows:

interface Filter<T> extends Predicate<T> {
     public boolean eval(T t) default { return isOK(t); }
     public boolean isOK(T t);
}

Now, existing instances of Filter become Predicates for free; the FooBar 
Commons APIs can be migrated over time to use the Predicate supertype, 
but old implementations of Filter can still work.

Or not.  The SotL document shows an idiom for converting from one 
functional interface to another (assuming the function shapes are the same):

   Predicate p = filter::isOk;

which really isn't such a painful conversion.

> One solution I could imagine would be to ship a set of functional
> interfaces that are expected to be common -- but then you firstly get
> into the problem of "how common is common enough?" and secondly, this
> just gets into the structural typing sphere by shoehorning it into the
> nominal typing sphere.

Yes, no matter how you squeeze the balloon, the air has to go somewhere. 
  This is the cost of not having crappy erased function types.  It seems 
the least of the obvious evils.

> I don't have a good solution, but just seems to me that having a few
> dozen interfaces that each define a single method with the same
> signature is not ideal.
>
> On Sun, Dec 11, 2011 at 7:57 PM, Brian Goetz <brian.goetz at oracle.com
> <mailto:brian.goetz at oracle.com>> wrote:
>
>     Because it just doesn't carry its weight.  The alternate version you
>     propose is one token shorter.  That would be adding incremental
>     complexity for no incremental benefit.
>
>     If I had to guess, I would think what you're really getting at is
>     that it is annoying to have to declare them as actual interfaces
>     (and worse, one class per file), instead of as a local type alias of
>     sorts in the class file that uses it.  Is that what you're getting at?
>
>
>
>         What about defining a new syntax for declaring functional
>         interfaces, so
>         that the interface as well as its implementation can address the
>         vertical problem? Something like:
>
>             interface MyComparable<T> = int compareTo(T other);
>
>
>         Which would be equivalent to:
>
>             interface MyComparable<T> {
>                  int compareTo(T other);
>             }
>
>         Apologies if this is also covered ground. I searched for java +
>         lambda
>         [dev] + delegate, since this seems a bit similar to C#'s
>         delegate syntax.
>
>         On Fri, Dec 9, 2011 at 3:32 PM, Brian Goetz
>         <brian.goetz at oracle.com <mailto:brian.goetz at oracle.com>
>         <mailto:brian.goetz at oracle.com
>         <mailto:brian.goetz at oracle.com>__>> wrote:
>
>             Yes, this is well-covered ground.  What you're asking for is
>         "function types" (or arrow types, or algebraic function types, or
>             structural functions types.)  The short answer is "no".
>
>             Function types are the "obvious right way" to represent the
>         type of
>             a lambda, until you realize that they will end up getting
>             implemented using generics, which means they will be erased.
>           Erased
>             function types are the worst of both worlds.
>
>             Instead, we use functional interfaces in APIs, and then
>         users can
>             use named classes, anonymous classes, or lambdas to create
>         instances
>             of the functional interfaces.
>
>
>
>             On 12/9/2011 1:44 PM, Yuval Shavit wrote:
>
>                 By the way -- and I apologize if this has already been
>         covered,
>                 I did
>                 some searching and nothing came up -- is there any
>         thought as to
>                 whether
>                 methods will ever be able to declare lambdas as arguments?
>                   Something like:
>
>                     public <T> void myFilter(Iterable<? extends T>, (?
>         super T ->
>                     boolean) predicate ) { ... }
>
>
>                 This function could then take either a lambda of the
>         same type,
>                 or any
>                 reference typed as a functional interface which could be
>                 expressed as a
>                 corresponding lambda.
>
>                 Thanks,
>                 Yuval
>
>                 On Fri, Dec 9, 2011 at 1:28 PM, Brian Goetz
>         <brian.goetz at oracle.com <mailto:brian.goetz at oracle.com>
>         <mailto:brian.goetz at oracle.com <mailto:brian.goetz at oracle.com>__>
>         <mailto:brian.goetz at oracle.com <mailto:brian.goetz at oracle.com>
>
>         <mailto:brian.goetz at oracle.com
>         <mailto:brian.goetz at oracle.com>__>__>> wrote:
>
>                     An updated State of the Lambda is available here:
>
>         http://cr.openjdk.java.net/~____briangoetz/lambda/lambda-____state-4.html
>         <http://cr.openjdk.java.net/~__briangoetz/lambda/lambda-__state-4.html>
>         <http://cr.openjdk.java.net/~__briangoetz/lambda/lambda-__state-4.html
>         <http://cr.openjdk.java.net/~briangoetz/lambda/lambda-state-4.html>>
>
>
>
>
>