Skip to main content
This revision made October 27, 2011 22:46, by Kin-man Chung

Lambda Expression in EL

To support query expressions on collections, it is necessary to pass EL expressions as argument to methods. These expressions will be evaluated in the methods. So essentially we need closures in EL. Fortunately, EL already has the concept of deferred expressions, so we just need to put the pieces together to add lambda expressions to EL.

An EL lambda expression is a deferred expression with parameters.

Syntax

The proposed syntax follows that of the one used in Lambda in JDK 8 http://cr.openjdk.java.net/~briangoetz/lambda/lambda-state-3.html

Of course the syntax in JDK is not final until it FCSed, but it is comforting to see the familiar syntax #{...}. :-)

Grammar:

  Lambda := '#{'  (ArgList '->')? Body '}'
  ArgList := Identifier (',' Identifier)*
  Body := Expression
  

Example:

  #{ 42 }
  ${x -> x+1}
  #{x,y -> x+y}

Operations on Lambda Expression

  • It can be assigned to a variable:
    fn = #{x -> x+1}
  • It can be invoked:
    fn(100) yields 101
    #{x, y -> x+y}(3,4) yields 7
  • It can be passed to a method:
    employees.where(#{p->p.name.first == 'Larry'})

API

We add a new class.

LambdaExpression.java see]

Note: the code for pluggin lambda argument will change.

Additional Considerations

  • It is not clear yet if we should use a new ELContext for evaluating the lambda body. If we use the EL variables to pass arguments values to the lambda expression , which seems natural, then using a new ELContext would ensure that those variables are properly scoped. OTOH, it seems restrictive that functions and bean discovery mechanism cannot be used in evaluating the lambda expression. The cleanest approach is to add a map in ELContext for Lambda arguments.
  • Current EL insists that functions be bound and mapped at parse time. This will not work well with lambda, which may be evaluated another JVM or even another machine. We'll need to consider lazy and late function binding at evaluation time.
Difference compared to previous revision
Of course the syntax in JDK is not final until it FCSed, but it is comforting to see the familiar syntax #{...}. :-) Grammar: Lambda := {'#{' | '${' } =Lambda Expression in EL= To support query expressions on collections, it is necessary to pass EL expressions as argument to methods. These expressions will be evaluated in the methods. So essentially we need closures in EL. Fortunately, EL already has the concept of deferred expressions, so we just need to put the pieces together to add lambda expressions to EL. An EL lambda expression is a deferred expression with parameters. ... *It can be passed to a method: employees.where(#{p->p.name.first == 'Larry'}) ==API== We add a new class. LambdaExpression.java [http://java.net/projects/el-spec/sources/source-code/content/trunk/api/src/main/java/javax/el/LambdaExpression.java see]] Note: the code for pluggin lambda argument will change. ==Additional (ArgList '->')? Body '}' ArgList := Identifier (',' Identifier)* Body := Expression ... employees.where(#{p->p.name.first == 'Larry'}) ==Additional Considerations== *It is not clear yet if we should use a new ELContext for evaluating the lambda body. If we use the EL variables to pass arguments values to the lambda expression , which seems natural, then using a new ELContext would ensure that those variables are properly scoped. OTOH, it seems restrictive that functions and bean discovery mechanism cannot be used in evaluating the lambda expression. *We'll nConsiderations== *It is not clear yet if we should use a new ELContext for evaluating the lambda body. If we use the EL variables to pass arguments values to the lambda expression , which seems natural, then using a new ELContext would ensure that those variables are properly scoped. OTOH, it seems restrictive that functions and bean discovery mechanism cannot be used in evaluating the lambda expression. Theed an API to pe clug in vealunes for the lambda aest apprguments before evaluatingroach it.s We'll need to to have to add a LambdaExpress a map ion (in ELConthat extends ValueExpressitext fon),r L anambd include a coda arguple of umenmethods to do this. *Current EL insists that functions be bound and mapped at parse time. This will not work well with lambda, which may be evaluated another JVM or even another machine. We'll need to consider lazy and late function binding at evaluation time. *I'm sure there'll be other issues.
 
 
Close
loading
Please Confirm
Close