Here's a very short rundown on the official syntax, with a link to the
last known proposal at the end. The current status quo isn't, as far
as I know, 100% the same as the 'official' proposal, because a new
version of the spec hasn't been released in months. There's also been
an encyclopedia's worth of traffic on concerns and disadvantages on
lambda-dev, but none of those have been discussed by Mark Reinhold,
Alex Buckley, Maurizio Cimadamore, or Brian Goetz, who all seem to be
involved in writing specs and implementations.
closures themselves come in two flavours. Either form is an
expression, whose type is a closure type:
inline expression form:
#(parameter list) ( expression )
block form:
#(parameter list) { any number of statements; }
The first form is syntax sugar for:
#(parameter list) { return expression; }
So, you can write:
Object plusClosure = #(int a, int b) (a+b);
which is the same thing as writing:
Object plusClosureLongForm = #(int a, int b) {return a + b;};
[Justification: In practice blocks have to be written in standard
style, so, line breaks after opening brace and before closing brace,
lest it look like a semi-colon party, but that means all closures are
multi-line, even very simple ones, such as plus, so, there's a short-
hand form if you can express the body of a closure as a single
expression. Also, inferring parameters is essentially impossible but
inferring return type and checked exceptions isn't, and closures
should be simple (and syntactically very brief), hence the inference.]
Note that 'long returns' doesn't work, you can't break or continue a
loop that your closure definition is in, nor can you return from the
method that your closure definition is in.
Also, the closure captures all variables from outer scope but you
can't actually interact with them unless they are final or effectively
final (effectively final = not marked final, but wouldn't cause an
error if they were marked as such).
The full type signature of a closure consists of 3 properties:
A) Parameter List. Read from the actual parameter list in the closure
definition.
B) Return Type. Inferred from the return statement (block form) or the
type of the expression (inline expression form)
C) (checked) throwables thrown. Inferred.
Obviously assigning a closure to an "Object" variable isn't very
useful. There are two useful type concepts you can assign them to,
function types and SAMs.
Function Types. These look like this:
#int(int, int)(throws IOException | SQLException) plusClosure = #(int
a, int b) (a+b);
[yes, good lord, that's some horrible syntax, I know - also the
official 1.5 spec on function syntax is riddled with errors particular
in regards to the throws syntax; alternatives that also might be valid
depending on where you look in the spec is "(throws IOException,
SQLException)" and just "(IOException, SQLException)".
justification: Without the extra parens around the throws clause the
parsing rule wouldn't terminate which isn't legal in LL(k) grammars
such as the ones used by most java parsers including javac. Or
something. I was a bit fuzzy on this, you may want to check lambda-
dev.]
function types can be 'executed' by using the dot. For example:
assert 15 == plusClosure.(5, 10);
[justification: In java, method names and variable names are separate
namespaces, so just closureVarName() would be looking in the wrong
namespace!]
Closures can also be assigned to SAM types. A SAM type is any type
that is (1) abstract and (2) has only one undefined method in it. In
other words, any interface that mentions only 1 method, and any
abstract class where all but 1 method has an implementation. Like
FileFilter and Runnable. Thus, this would work just fine:
Runnable r = #() {System.out.println("Hello, World!");};
r.run(); //Will say hi to world.
r.(); //This wouldn't be legal; r is a Runnable, not a #()().
The mechanics for realizing that the above closure declaration, which
is of type #()(), can be 'fitted' safely into a java.lang.Runnable
SAM, requires lots of complex inference rules. This inference includes
the reasoning that returning something is compatible with returning
nothing, an inference that doesn't occur anywhere else in java. E.g:
#void(Integer a) = #(Number a) (a);
is legal. If you throw enough generics in the mix, the errors are
going to balloon into gobbledygook. Nevertheless, SAMs are what
today's java libraries run on, so any closure proposal that cannot
'autobox' themselves into a SAM type would be even worse.
"this" in a closure refers to the closure object. This seems nuts but
has been added for the benefit of allowing closures to recurse into
themselves. However, you'd get an endless loop when trying to infer
return type if you actually returned 'this', so the following is
explicitly defined as a compiler error:
Object closure = #() (this); //Infer the return type on this miracle!
The actual way closure types are created most likely will involve
generics of some sort, so arrays of closure types, like so:
#()[] = new #()[10];
aren't legal for the same reason you can't write new T[10];
Link:
http://mail.openjdk.java.net/pipermail/lambda-dev/attachments/20100212/af8d2cc5/attachment-0001.txt
On May 31, 8:07 am, Mark Derricutt <[email protected]> wrote:
> I realllllly don't like the look of them. If they'd reused { } around the
> actual method call I'd be much happier. But reusing ()?
>
> --
> Pull me down under...
>
> On Mon, May 31, 2010 at 5:58 PM, Michael Neale <[email protected]>wrote:
>
>
>
>
>
> >http://www.baptiste-wicht.com/2010/05/oracle-pushes-a-first-version-o...
>
> > I guess most of the attention has been on the semantics (and rightly
> > so) but wow... just wow.
>
> > (sorry to interupt the appleposse with java news).
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "The Java Posse" group.
> > To post to this group, send email to [email protected].
> > To unsubscribe from this group, send email to
> > [email protected]<javaposse%2bunsubscr...@googlegroups
> > .com>
> > .
> > For more options, visit this group at
> >http://groups.google.com/group/javaposse?hl=en.
--
You received this message because you are subscribed to the Google Groups "The
Java Posse" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en.
