related link

[Neal Gafter]

On Mon, Feb 8, 2010 at 9:21 AM, John Nilsson <john at milsson.nu> wrote:
> In my, admittedly rather naïve, mind such a static construct could
> be modelled as transparent closures with the added restriction that it is to
> in-lined at compile time, and as such would disallow any treatment of them
> as run-time constructs. F.ex. moving references around would be a static
> error.
> The rather narrow goal in my mind being to allow "non-local returns" without
> the scary stuff ;)
> When you said "has been shown" did you have any particular paper in mind?
> (I'm rather curious about PL-research)
> BR,
> John

John-

If you want to continue this discussion, please join the closures-dev
mailing list.

Inlining at compile-time only works for very restricted kinds of APIs,
and excludes many interesting and useful APIs that could be written
using transparent lambdas.  See, for example, my blog post on
concurrent loops
<http://gafter.blogspot.com/2006/10/concurrent-loops-using-java-closures.html>,
which has been implemented by Mark Mahieu
<http://markmahieu.blogspot.com/2008/08/for-eachconcurrently.html>.
That is just not possible with the approach you suggest.  Inlining
also undermines binary compatibility, which is one of Java's
strengths.

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.

For writings about the expressive power of transparent lambdas, one
place to start would be Steele and Sussman's 1970's "Lambda the
Ultimate..." papers
<http://en.wikipedia.org/wiki/History_of_the_Scheme_programming_language#The_Lambda_Papers>.