call operator and orthogonality with existing VM internals

[Neal Gafter]

Jakob-

I did not see your original message, but I have some thoughts:

o I do not agree that it is practical to blur the distinction between
statement and expressions in Java's future.
o The ability to 'shortcut" the call operator x.call(e) as x(e) raises
some difficult issues with name lookup that have not yet been solved,
which is why a different syntax is being considered.
o Functions as interfaces is one option explored in detail in BGGA.
The alternative of using MethodHandle is being considered for project
lambda.
o Currying and method references in the source should not require
going through type-unsafe intermediaries such as reflection.

Cheers,
Neal

On Mon, Mar 8, 2010 at 9:25 AM, Jakob Praher <jp at hapra.at> wrote:
> This line
>   Function<String,String> echo = echoMethod.bind(this);
> should actually be
>   Function<String,String> echo = echoMethod.bind(myinstance);
>
> Jakob Praher schrieb:
>>
>> Dear List,
>>
>> I was thinking much about the syntax of the upcoming language changes
>> regarding the introduction of
>> * first class functions
>> * first class function types
>> * lambda expressions ("closures")
>>
>> While IMHO the best would be to refactor certain aspects of the language
>> (e.g. blur the distinction between Statements and Expressions, especially
>> treat "blocks" as expressions, change the call expressions to allow custom
>> control flow constructs, ...).
>>
>> Since I am realistic in that such changes will not be doable for version
>> 7, I think one should seek orthogonality and consistency in integrating
>> these new constructs.
>>
>> I would suggest the following:
>> * Add a call operator (e.g. a special purpose "call" method) that can be
>> short-cutted to x() instead of x.call(...)
>> * Treat a function as an instance of java.lang.Function<ReturnType, ArgT1,
>> ..ArgTn> that implements this call operator
>> * Add a special keyword "lambda" for creating an instance of a Function
>> from a Block (this is in the tradition of "synchronized" and friends):
>>    Function<Integer, Integer> square = lambda(int x) { return x*x ; }
>>
>> * Introduce a bind method that converts a method to its lamba form
>> (currying the this away):
>>    class MyClass {  String echo(String x ) { return x; } }
>>    Method echoMethod = myinstance.getClass().getMethod("test");
>>    Function<String,String> echo = echoMethod.bind(this);
>>    System.out.println( echo("Hello") );
>>    System.out.println( echo.call("Hello") );
>>
>> Some Reasons:
>> * Is IMHO more consitent with current Java
>> * Reflection concepts like Class, Method, ... are "magic VM" instances too
>> * AtomicInteger.compareAndSet can be internally optimized to single CAS
>> instruction too
>>
>> What do you think about this?
>>
>> -- Jakob
>>
>>
>>
>>
>>
>>
>
>