related link

[Neal Gafter]

On Mon, Feb 8, 2010 at 2:45 PM, John Nilsson <john at milsson.nu> wrote:
> On Mon, Feb 8, 2010 at 8:03 PM, Neal Gafter <neal at gafter.com> wrote:
> A quick and dirty pretend syntax (didn't really spend too much time thinking
> about concurrency, but I'm assuming that any issues can be address within
> the macro construct).

The problem isn't syntax, it's semantics.  I don't see how your API
makes return/break/continue "do the right thing" from the API client's
point of view.  You seem to treat break and return identically, for
example, but they don't have the same meaning at all.

>> FYI, experience with languages that support "non-local return" (Scala,
>> Ruby, etc) has resulted in a remarkable absence of scary things
>> happening.  They're really quite boring and ordinary once you try
>> them.
>
> I guess you are right. But I still feel uneasy about it. The current closure
> semantics of java allows me to think (am I wrong?) that the stack frame and
> everything related to it will be completely forgotten once the method
> returns.

Yes, that's also the way it works in BGGA (and Scala, Ruby, etc).

> What happens to stack frames to which we can return from closures
> that has been saved away?

The same thing that always happened to it.  When you return from a
method its stack frame goes away.  Captured (local) variables might
survive, though, just as they do with anonymous inner classes and
project lambda.

> Is it saved away as a continuation?

Nope.  That's an interesting alternative but nobody has proposed it,
and I don't think it works out well in Java.

> Are they
> garbage collected? Will lots of deeply nested calls pollute my heap if I
> don't allow the lambdas to get garbage collected? Do I need to worry about
> these things?

Nope.  They just go away when you return from the method.