capturing (or not) mutable local variables

[Howard Lovatt]

@Jim & Llewellyn,

You raise a number of points:

1. To me the proposed lambdas are consistent with Java, in particular
with inner classes (which also only close over finals). The type of
the lambda must be a SAM, which means it could be an instance of a
class (including inner class) or a lambda, therefore it is important
that something written to work with an inner class works with a
lambda.

2. As others have pointed out fields can be marked volatile and locals
can't, which helps in making a lambda thread safe when writing to a
field (and it would be hard to add volatile to a local).

3. In Haskell a closure that interacts with mutable state via a monad
can't, in general, be passed to a non-monodic function or vice versa
(and this can be a pain and is an active area of research in the
Haskell community to remove this restriction). In the proposed lambda
model you can pass the lambdas freely to anything, that is a nice
feature (you don't need to know the details of the function you call).

4. I agree that Java isn't the ideal parallel language, but lets learn
from the mistakes of others and move away from mutable state and set
Java up as better than C#, Scala, Lisp, etc. in the parallel domain.
Tell people that if they want mutable state they should use AtomicXXX
to guarantee thread safety. It is a pity that Java didn't make
everything immutable in 95 and that you have to mark stuff as mutable
using AtomicXXX (however this is looking back 15 years and it is very
easy to spot mistakes in hindsight and the fact is that Java was much
better than anything else in 95 and did provide state of the art
parallel constructs for 95).

Cheers,

 -- Howard.

On 22 November 2010 17:39, Llewellyn Falco <isidore at setgame.com> wrote:
> I also want to point out that there seems to be an assumption that the
> consumer of the lambda has ANY idea that creator of the lambda USED a
> lambda.
> Remember that the signature for someone using a lambda will be like
>
> public <T> List<T> where(Func<T,Comparable> f)
>
> The fact that you created the Func SAM interface with a lambda is not known
> to the user of the lambda.
> Therefore, the idea that some of the creations might be thread safe, isn't
> very useful.
>
> Llewellyn



-- 
  -- Howard.