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