transparent lambda

[Neal Gafter]

On Thu, Dec 31, 2009 at 12:21 AM, <tronicek at fit.cvut.cz> wrote:

> Just to be sure I know what you are talking about: do you mean overflow?
>

Yes.


> Another question, which was already here, is, whether such escape of
> closure would be allowed. If invocation of #() { return 2; } is always
> error after returning from the first four(), it would be better to forbid
> such escape.
>

Yes, it would be better, if there existed a static flow analysis to enforce
this restriction that is both conservative and strong enough to allow
virtually all of the kind of safe code that you can write without the
analysis.  I spent some time looking for a way to do it, and I didn't find
one.  None of the existing languages that support nonlocal transfers
implement such an analysis, so we'd be breaking new ground if we found a way
to do it.

I should also point out that the runtime exception that is caused by this
failure is remarkably easy to track down.  I think you'd be hard pressed to
find reports of a smalltalk/ruby/scala/clisp programmer complaining about
accidentally triggering these errors, or having a hard time tracking them
down.  They're about as debuggable as array-index-out-of-bounds errors.

Cheers,
Neal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/closures-dev/attachments/20091231/10ee5692/attachment.html