Updated State of the Lambda
Yuval Shavit
yshavit at akiban.com
Sun Dec 11 18:53:26 PST 2011
On Sun, Dec 11, 2011 at 8:39 PM, Brian Goetz <brian.goetz at oracle.com> wrote:
> 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.
My initial thought (back from my first email) was that the compiler would
be free (but not obligated) to translate the function type to an
anonymous-style interfaces. But I'll fully admit I haven't thought out all
the corner cases, and if you say it's not feasible, I'll defer to the
experts.
> 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!
It's definitely winning, no question about that. I'm just wondering if
there's a way we can run up the score.
As far as shifting work to library producers, I agree that's the right
direction. That said, there's a lot of API/library-type work that happens
not in 3rd party libs specifically designed to be general, but just in
projects where the expected consumer is "the guy in the desk next to me,"
not "anyone and everyone." In those cases, making composition easier may be
the nudge they need.
> 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>
>> >
>> <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>
>> >>
>>
>>
>>
>>
>>
>>
More information about the lambda-dev
mailing list