[bitc-dev] A consequence of treating blocks as lambdas

[Stuart Cook]

On Fri, Sep 3, 2010 at 9:55 PM, Jonathan S. Shapiro <shap at eros-os.org> wrote:
> On Thu, Sep 2, 2010 at 9:03 PM, Stuart Cook <scook0 at gmail.com> wrote:
>>
>> If a naked {} block doesn't have the obvious/traditional meaning then
>> I assume that you'll issue a very stern compiler warning (error?) upon
>> finding one.
>
>
> I'm not sure what obvious/traditional meaning you expect, and I can't think
> of any case where this proposal would create a problem with an empty block.

Sorry, I wasn't clear before. I just wanted to make sure you had
considered one of the non-obvious side-effects of treating blocks as
lambdas.


In a typical language with blocks (C, Java etc.), a bare block on its
own is a statement that simply executes its contained statements
immediately (in a nested lexical scope if appropriate). This is the
“traditional” behaviour.

If blocks are instead treated as lambdas, a bare block on its own
could be interpreted as an expression that evaluates to a lambda,
which itself never actually gets called. This is consistent, but also
confusing.

Consider the following code snippet:

  a()
  {
    b()
  }
  c()

If {} blocks are treated as lambdas, then (in the absence of extra
rules) the above code will call functions 'a' and 'c' but not 'b',
because the call to 'b' is inside an anonymous function that is never
called.

(This situation is of course easy to fix, either by disallowing or
discouraging bare blocks or by special-casing them to execute their
contents.)

All of this assumes that I've understood you correctly, which
naturally is not guaranteed.


Stuart Cook