Re: new Java lambda syntax
On 9/11/2011 3:07 PM, Joshua Cranmer wrote:
On 9/11/2011 2:14 PM, Steven Simpson wrote:
On 11/09/11 19:08, BGB wrote:
I would have also liked to see lexical variable capture.
FFS, I added this (along with closures) to a C compiler before, can't
be too hard
At this stage, I don't think the issue is how, but whether/when to
permit it.
There are other issues like does it capture the value or does it use the
same variable. e.g., what would this produce:
List<Runnable> runners = new LinkedList<Runnable>();
for (int i = 0; i < 10; i++) {
runners.add(() => { System.out.println("Value of i is " + i); });
}
for (Runnable r : runners) {
r.run();
}
Should you see 0..9 or 10 repeated 10 times?
most languages I am aware of with closures (and mutable state) capture
the variable itself, so one would see 10 repreated 10 times (since the
original variable now holds 10).
in a different context, I had run into this issue, and added a special
form to the block (theoretically, IIRC not yet implemented) to
explicitly capture the state of the variable at that point (rather than
a reference to this variable). interestingly, this internally converted
into a closure which accepted the variables as arguments and was then
called with these variables.
a more generalized form of this would look something like:
for(i=0; i<10; i++)
begin(i) {
...
}
....
with "begin(i) { ... }" basically meaning to execute '...' with 'i'
having been captured (by value).
this could also be user like "begin(i, j) {...}" to capture two values,
or "begin(i, j=i*251) {...}" to capture the value of i and bind j as a
computed value (sort of like "(let)" and friends in Lisp and Scheme).
however, I have doubts that such a feature would map nearly so cleanly
to Java or the JVM.
in C++0x, the type of variable capture was made explicit in the lambda
syntax:
"[](...) {...}" (no capture allowed)
vs
"[&](...) {...}" (capture by reference)
vs
"[=](...) {...}" (capture by value).
vs
more complex forms...
For invocations, having to type obj.run() instead of obj() is hardly
onerous. Plus, invocations will be much rarer than lambda declarations.
Also note that the invocation site is unaware of whether the object is a
lambda.
Also, note the (slight) benefits of explicitly saying what you are
doing. You might choose, reasonably, to call the callback parameter for
an asyncForEach function `block', at which point the functional call
specification becomes block(value), which can be visually ambiguous as
to what it's doing. block.call(value) is clearer, on the other hand.
yes, but I guess it depends some on what one is doing, and whether or
not it is better to complicate some potential use cases for sake of
preventing people from shooting themselves in the foot in others (or,
OTOH, gloss over certain complexities at the risk of people then
shooting themselves in the foot...).
or such...