

Project Lambda: Straw-Man Proposal - alrex021
http://cr.openjdk.java.net/~mr/lambda/straw-man/

======
alrex021
Here is a link to some latest comments/thoughts on straw-man proposal:

[http://mail.openjdk.java.net/pipermail/lambda-
dev/2009-Decem...](http://mail.openjdk.java.net/pipermail/lambda-
dev/2009-December/000023.html)

------
RyanMcGreal
Can someone please explain where an anonymous function has an advantage over a
named function? (Not trolling: I'm really trying to figure it out.)

~~~
joubert
One example is when you want to pass a function as param to another function.

JavaScript example: Forced to use named function:

var greaterThanFunction = function(a, b) { return a > b; };

var filteredResults = filter(biglist, greatherThanFunction);

VS:

Anonymous:

var filteredResults = filter(biglist, function(a, b) { return a > b; });

The JavaScript example above is nice, but in Clojure anonymous lambdas are
even nicer:

You can do things like:

(reduce #(+ %1 %2) (range 1000))

i.e., not only do you not have to name the function, you don't even have to
name the variables.

\----

Excerpt from <http://clojure.org/reader>

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.

------
caffeine
There's a quote somewhere about every sufficiently complicated program, and
every sufficiently developed language, eventually trying to badly replicate
Lisp.

~~~
Hexstream
<http://en.wikipedia.org/wiki/Greenspunning>

"Any sufficiently complicated C or Fortran program contains an ad hoc,
informally-specified, bug-ridden, slow implementation of half of Common Lisp."

------
geocar
Am I missing something? There doesn't seem to be any way to pass a function in
the function namespace as a variable without a closure.

~~~
ewjordan
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.

------
Tichy
I don't see the point?

~~~
brown9-2
_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._

~~~
Tichy
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.

