return-from-lambda viewed as dangerous, good alternatives

[Joshua Bloch]

Neal,

I'll leave it to Mark to decide what's appropriate for the list. But I
believe your use of the term "transparency" is loaded. Calling it
"transparency" makes it sound like a good thing, when it is at best a mixed
blessing. I'm not saying that you did this intentionally, but I do think
it's worth pointing out.

In plain terms, what the proposed use of the return keyword excludes is *using
lambdas to emulate control constructs*. That's an explicit non-goal of this
effort. The participants in this effort must  do their best to provide
anonymous function objects, even if this means the resulting construct can
never be used to emulate control constructs.

             Josh

On Fri, Jan 8, 2010 at 3:35 PM, Neal Gafter <neal at gafter.com> wrote:

> On Fri, Jan 8, 2010 at 3:14 PM, Alex Buckley <Alex.Buckley at sun.com> wrote:
> > BGGA offered transparency and non-transparency via unrestricted and
> > restricted function types and closures. CfJ 0.6a and 0.6b, taken
> > together, offer both too. The differences are well understood.
> >
> > However, the Project Lambda strawman - and this list - are about
> > non-transparent a.k.a. restricted lambdas. I will soon be sending a
> > draft spec for lambdas as envisaged in the strawman. Hopefully further
> > discussion about transparency can occur on closures-dev, as Neal said
> > earlier.
>
> The point of intersection is checking that Sun's Project Lambda does
> not preclude transparency.  That discussion is appropriate here, no?
>
> Cheers,
> Neal
>
>