return when desugaring to closures

[David-Sarah Hopwood]

Yuh-Ruey Chen wrote:
> Mark S. Miller wrote:
>> On Sat, Oct 11, 2008 at 4:33 PM, Dave Herman <dherman at ccs.neu.edu> wrote:
>>>    Expression ::= ... | lambda Formals? Statement
>>>
>> Statement or SubStatement? If Statement, what meaning do you propose for
>>
>> {
>>     const f = (lambda () const x = 3;);
>>     .... x ....
>> }
>>
>> Does the const export its binding into the lambda's enclosing block,
>> such that the x on the next line refers to that x? I hope not.
>>
>> If the answer is SubStatement, then changing the answer to Block in
>> order to require the curlies may very well help people understand the
>> scope relationships across the lambda boundary.
> 
> Now that I think about it, would it truly be necessary for lambda to
> create an implicit block scope in the first place?

It's not strictly necessary, but it's quite ugly not to. We are intending
to restrict 'eval' precisely to remove the ability to inject bindings
into the surrounding scope (although 'eval' is worse because the scoping
it creates isn't statically analysable).

> |lambda() return 10|
> would not require such a block scope. Why not have the block scope only
> created if there are curly brackets? That would follow the precedent set
> by the rest of the language with regards to block scope

No, that would be entirely inconsistent with the rest of the language:

  { while (...) let x = ...; }

is equivalent to

  { while (...) { let x = ...; } }

not

  { let x; while (...) { x = ...; } }

> with the exception of |for (let x...) ...|.

I don't think that such an "unscoped" lambda provides enough (if any)
value to justify its complexity.

-- 
David-Sarah Hopwood