Re: a convert to lambda-ism

On Mon, 15 Nov 2010, Joshua Cranmer wrote:


Yes. I literally punched the air when i read:

 There is no non-local transfer of control in this proposal, in contrast
 to BGGA.

I thought i was the only one who thought the 'return returns from the
enclosing scope' was batshit insane.


Amen to that, brother. Also, it had maximally horrid syntax. Even
Reinhold's 'strictly provisional' syntax is better!


The terseness lends itself to the typical higher-order-function uses,
like:

List<String> names;
List<Integer> lengths = names.collect(#(String s) (s.length()));

Adding the return to that makes it noticeably, although of course by
no means fatally, clunkier.


Agreed.

And i'm surprised non-shared closed-over variables aren't required to
be declared final, but must only be 'effectively-final'. That seems
un-javalike.


Could you expand on that? I don't know how to even begin thinking
about the interaction with types.

Mind you, having seen what's happened to the type system around
invokedynamic, i am no longer sure that such concerns are actually a
roadblock to implementation, sadly.


Given that we won't be able to add lambda-aware methods to existing
collection interfaces, because that would break all existing code
which implements them, extension methods are the only way of being
able to write the example i give above, or do anything along those
lines (map, filter, reduce, and friends). Having lambdas but not being
able to do those things would be agonizing.

Also, i really don't like the implicit function conversion. I
appreciate that there are millions of places where we'd like to use
first-class functions where we currently use these 'SAM' (Single
Abstract Method - i had to look it up) types, but i don't think we
should be catering to that in the language. For the most part, the
classes which currently demand SAM types are ones in the standard
library (Collections, Arrays, Thread) which could easily be enlarged
to take lambdas too. Where there are interfaces which we'd like to
expand, we can use extension methods:

package java.util.concurrent;

public class ExecutorService {
    public static Thread newThread(ThreadFactory self, #void() fn) {
        return self.newThread(new Runnable() {
            public void run() {
                fn();
            }
        });
    }
}

import static ExecutorService.newThread extends ThreadFactory; // my suggestion

ThreadFactory factory;
Thread t = factory.newThread(#() {doStuff();});

There are tons of other things extension methods would be useful
for. I think once you had them, you'd wonder how you ever lived
without them. For instance, you'll immediately be able to say:

import java.util.List;
import static java.util.Collections.sort extends java.util.List;

List things;
things.sort();

Wouldn't that be nice?

C("BBTAA","001","","","","","","","","","","Portafotografia
argento","","","","","","","","","19.00","","","1000","ard","verif","","","","","","0"));