related link

[John Nilsson]

On Tue, Feb 9, 2010 at 8:22 PM, John Rose <John.Rose at sun.com> wrote:

> Regarding the specific dangers of uplevel branch: An unmatched uplevel
> branch, which causes an exception when executed, is annoyingly dynamic.  It
> is self-diagnosing, exactly like a NPE or CCE.  And BGGA has a novel static
> check for restricting branches to appropriate APIs, so there's a static
> story too, unlike NPE or CCE.  And (as those who have used such things know
> by experience) the problem comes up much less often than NPE or CCE does in
> Java.
>

I had assumed, wrongly I now discover, that the return would always succeed,
whatever that meant. Throwing an exception feels safe enough for me.
=) "Annoyingly dynamic" is a perfect description of how I feel about that.

It does strike me that it creates two classes of lambda consumers. Those
which it is safe to use control transfer with, and those that it isn't. Will
this introduce problems for APIs that accidentally belongs to one class and
later want to migrate to the other class?

Compared with the largely-hypothetical dangers of uplevel branches, I am
> personally much more afraid, based on experience with Lisp, of unexpected,
> undiagnosed effects of the "dotimes bug"[1] with captured mutable locals.
>
Given the UnmatchedTransferException solution I'm in full agreement.

I like the current Java requirement that variables need to be final. I could
live with a design where non-final variables would be shadowed by final
versions implicitly introduced within the lambda-body. This would solve some
annoying cases where it would be easier to use variables outside the lambda
body.

Intuitively I like to think that a closure closes over values, not names,
they are just automatically bound to the same names within the closure. But
I guess I can always be re-trained if needed.

BR,
John

p.s. unless it seems to off topic I'd still like to work out the edges of my
macro suggestion because I still feel that some things are "annoyingly
dynamic" ;-)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/closures-dev/attachments/20100209/3f6240fd/attachment.html