capturing (or not) mutable local variables

[Florian Weimer]

* Brian Goetz:

>>> In a parellel world, this idiom is irretrievably broken.
>>
>> I fear that such an extreme focus on concurrent programming is rather
>> unhealthy for a general-purpose language.
>
> How can you possibly (with a straight face) describe the choice to
> *not* add a controversial feature as being an "unhealthily extreme
> focus"?

Sorry, I just don't think "it doesn't work in a concurrent program" as
a valid argument.  Hardly anything works well in large, concurrenct
systems, after all, so this argument is always valid in some way.

I would certainly accept the argument for features which cause global
concurrency issues (examples for that are POSIX APIs such as umask,
chdir, setuid, fork/sigprocmask/waitpid etc.), but here, we're dealing
with a potential local correctness issue which would not affect
indepedent code on the same VM at all, including code which uses the
same feature correctly.

Furthermore, when the compiler detects non-local mutation of a
variable within a closure (which could even include class members), it
could mark the generated object in some way, and a hypothetical
parallel forEach() could check this flag and throw.  This means that
you'd get a helpful exception, instead of silent corruption.  (I don't
think you should express this in the SAM type itself because you can
use interfaces such as Runnable in both parallel and non-parallel
contexts.)

On the other hand, implementing *efficient* closures over mutable
variables is surprisingly difficult, particularly if you want to avoid
space leaks, so I certainly won't argue strongly for them.  I think
they would provide a useful addition to the language, though.

-- 
Florian Weimer                <fweimer at bfk.de>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99