Anonymous function literal (#())
#(...) => (fn [args] (...))
where args are determined by the presence of argument literals taking the form %, %n or %&. % is a synonym for %1, %n designates the nth arg (1-based), and %& designates a rest arg. This is not a replacement for fn - idiomatic used would be for very short one-off mapping/filter fns and the like. #() forms cannot be nested.
One of the biggest is that anonymous functions typically are less verbose in terms of syntax required. This is really dependent upon the language you're working with but two pretty decent examples from languages I work with are Ruby and javascript. In javascript, an anonymous function is just a normal function with no name:
function(){ return "i'm anonymous"; }
function namer(){ return "i'm a named function"; }
In Ruby, blocks are a syntactic sugar for anonymous functions:
[1,2,3,4].each {|num| print i } # => 1234
[1,2,3,4].each do |num| print i; end # => 1234
In javascript a named function is very similar to an anonymous one - they can both be bound to variables, both be passed to other functions, both be returned from functions. I believe the biggest difference you'll find is that some languages enable you to write them with very little trouble (e.g. the ruby given above, simply brackets with an arg list) while some require more extensive declaration. Another good contrast of this is javascript, which doesn't even require that you give a function a formal parameter list, with (hypothetically) Java which will need both a return type and the types of each argument.
If you had to come up with a unique name for every "one-shot" function (which you need a lot in a functional language), you'd have to expend brain-cycles every time to either decide on a representative name (which can be long and/or difficult to come up with if that function does something pretty idiosynchratic, which most one-shot functions do) or use an ugly, meaningless naming scheme like "myfunction1, myfunction2, myfunction3".
There's a quote somewhere about every sufficiently complicated program, and every sufficiently developed language, eventually trying to badly replicate Lisp.
To my knowledge, what you're talking about is still on the table if it can be worked out in a reasonably sane manner, but it's tricky.
Not that this is an excuse not to do it, but it's not straightforward even to spec out, let alone agree on and implement: Java has some painful differences between variable and function namespaces, not the least of which is that methods are polymorphically resolved whereas member variables are looked up based on declared type.
So what should happen we try to assign a function as a variable: should it be looked up based on runtime class, or declared class? Either way, there are going to be gotchas, and what you'd think might happen is not what actually happens. There's just no way to allow Java methods to become transparently interchangeable with variables in the face of inheritance, so some of Joe Java's assumptions will probably have to be broken for it to work right.
IMO it would be best to just go back and rewrite the variable namespace rules to be a little saner (is it ever really necessary to shadow a superclass variable? Scala gets along fine without allowing var overriding...), but that's never going to happen, so...
This leads to other frictions, too: one issue that's been causing some friction is that nobody has yet fully worked out how to allow closures to be called using m(args) syntax instead of m.invoke(args), because of these same namespace issues. That one is on a lot of todo lists because using the things will be overly verbose if it's not done, but there's a lot of subtlety in the edge cases, so I'm not sure how it will all fall into place.
Everyone should keep in mind, though, the proposal linked on this page is a very rough draft, and is likely to be altered in many, many ways. Neal Gafter has been working pretty hard to try to bring his latest proposals (see http://www.javac.info/ for links) closer to where the official proposal is likely to go (i.e. a simpler and slightly less powerful compromise), so more of what was in BGGA might show up in the final Java 7 spec than Mark's strawman proposal would indicate.
It’s intended to be a starting point for discussions on the Project Lambda mailing list which will, hopefully, lead to the formulation of a detailed proposal and a prototype implementation.
Missed that, thanks. Might have been clearer if they had labeled it "starting point for discussion" rather than straw man.
I am not sure if redefining the whole Java language completely is really useful. Why not just switch to another language entirely.
Perhaps it would be more useful to improve support for functional languages in the Java VM. But Java itself can only get worse by piling even more syntax options on top of it.
http://mail.openjdk.java.net/pipermail/lambda-dev/2009-Decem...