call operator and orthogonality with existing VM internals
Jakob Praher
jp at hapra.at
Mon Mar 8 09:22:37 PST 2010
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
More information about the lambda-dev
mailing list