capturing (or not) mutable local variables

[Pavel Minaev]

On Sun, Nov 21, 2010 at 5:45 PM, Howard Lovatt <howard.lovatt at gmail.com> wrote:
> I think Brian and Co. have got this one right; the future is multicore
> and parallel processing, no point introducing something that will be
> an ever increasing pain point. We should be looking to our parallel
> future, not our serial past.

It just seems strange to do so in one particular - and relatively
small - corner of a language that otherwise heavily promoted
imperative approach and mutable state. Looking out to parallel future
requires languages designed from ground up to conform to that model.
Java is not such a language. It cannot be reasonably be made into such
while remaining the same language in anything but name.

As others have noted already, it is especially strange to restrict one
particular use case (mutable locals), but leave others (mutable
fields, including indirectly via getters/setters) - which are just as
likely to occur - be. If anything, this may provoke the user of the
language into false sense of security early on, "if it compiles then
I'm not doing anything wrong" - and then trip him over when it comes
to just slightly more complex code.

Overall, it really seems that the very broad feature such as closures
is being deliberately narrowed down to some very specific use cases to
justify the constraints. I find the claim that closures will mainly be
used in multithreaded context rather dubious - of all other mainstream
languages which have closures that I know of, the majority of uses are
in single-threaded context. If we look at C#, as the language that is
closest to Java both semantically and in terms of intended use
scenarios, again most uses of lambdas there are for more concise and
clear code, and not for parallelization.

Future may change that, but I think that for a mature language such as
Java, designing language features with a crystal ball in hand is
ill-advised. Far better to note how the same feature is designed and
used elsewhere _today_, and build on that.

> I should state my bias, in that I like a functional approach and I am
> much more influenced by the likes of Haskell than Lisp. I also find
> the argument that you can't have closures without writing to variables
> strange since languages like Haskell are normally treated as having
> closures but don't have write access. Also in Church's Lambda calculus
> there was no write at all!

The difference is that Haskell (and other similar cases) does not have
mutable variables in general, so of course it wouldn't have that in
closures, either. In that respect, it is fully consistent.

However, all languages - including those with traditional functional
background, such as Scheme or ML - which have mutable locals, also
capture that mutability in closures. This is simply by definition of
closure, which is a capture of the environment - if said environment
is mutable, then that aspect of it should also be closed over.