java.lang.StackOverflowError in Lowering

Alessio Stalla alessiostalla at gmail.com
Wed Jun 22 14:38:02 PDT 2011


On Wed, Jun 22, 2011 at 11:09 PM, Neal Gafter <neal at gafter.com> wrote:
> On Wed, Jun 22, 2011 at 11:16 AM, Alessio Stalla <alessiostalla at gmail.com>
> wrote:
>>
>> Anyway, the
>> important thing here is that, in Java, not having mutability of
>> captured variables is at worst a minor annoyance; if you really want
>> it, you can easily fake it one way or another, so there's no reason to
>> complicate the compiler.
>
> Indeed, one could say the same thing about mutable local variables even in
> the absence of lambda expressions.  If we're going to deprecate mutable
> local variables without breaking backward compatibility, we might as well
> start now, and allow them to interoperate with only previously existing
> language constructs.

:) I don't know how to answer... because I don't really understand the
point you're trying to make.

 - Mutable local variables are evil? Then don't use Java. Or use it to
write a Haskell compiler targeting the JVM ;)
 - Inconsistencies are bad? They are, but lambdas don't add new
inconsistencies (well, at least not about mutable captured local
variables ;)
 - No-mutable-captured-variables was too strict a restriction even
before lambda? Perhaps it was; I disagree; but I don't see why project
lambda would have anything to do with it, given that lambdas are
syntax sugar for SAMs and the limitation affects inner classes, which
is a set that intersects with SAMs but is neither a superset nor a
subset. If anything, it would be more in scope for project coin, I
think.
 - No-mutable-captured-variables prevents lambdas to be used
seamlessly as code blocks in control abstractions? I know you'll
disagree about that, but I strongly believe that closures and blocks
are conceptually different things [*]. That one can be implemented
using the other does not change that.
 - ...?

[*] not considering that lambdas as proposed are not even proper
closures but mere syntax sugar for SAM interface implementations...

Cheers,
Alessio "Trollfeeder" Stalla


More information about the lambda-dev mailing list