Closures for Java (0.6) specification part b
talden at gmail.com
Mon Dec 14 13:39:07 PST 2009
That seems reasonable. Also, thanks for pointing out the obvious URL
fiddling of 0.7.
On Tue, Dec 15, 2009 at 9:55 AM, Neal Gafter <neal at gafter.com> wrote:
> Good point. I'll add the following note as a clarification at the end of
> the control invocation syntax section in the next revision:
> Note that a consequence of this specification is that a break, continue, or
> return within the body of a control invocation can transfer to a target
> outside the control invocation statement. That is not a separate language
> rule, but a consequence of the meaning of the individual language elements
> that make up the specification of the control invocation statement.
> Can this be said more clearly?
> You can see working drafts of the 0.7 documents by guessing the URLs.
> On Mon, Dec 14, 2009 at 12:42 PM, Talden <talden at gmail.com> wrote:
>> On Tue, Dec 15, 2009 at 8:50 AM, Neal Gafter <neal at gafter.com> wrote:
>> > On Mon, Dec 14, 2009 at 11:47 AM, Jonathan Gibbons
>> > <Jonathan.Gibbons at sun.com> wrote:
>> >> Ouch. That's pretty subtle, especially as the statement in a control
>> >> invocation form is defined to use an expression lambda instead of a
>> >> statement lambda.
>> > Maybe subtle for the specification, but not subtle for the Java
>> > programmer,
>> > as you don't see a lambda when you're writing a control invocation.
>> I think that's a really significant point that warrants clear mention
>> in the documentation. It comes up frequently yet, as you say, this is
>> a subtle point of confusion for reading the specification not reading
>> and writing java code.
>> From the developers perspective they're not writing a lambda, they're
>> writing a local block of code - continue, break and return should act
>> as though they're local.
>> Aaron Scott-Boddendijk
More information about the closures-dev