I feel like I'm being obtuse here, Stuart, but I'm still not seeing the
problem. Your initial statement of context:
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.
>
Makes it clear that we're talking about two different things. What I'm
saying here, quite simply, is that {} in bitc simply doesn't mean "block".
It means lambda. But in many contexts where a block would be expected (e.g.
LET), the surrounding syntactic element evaluates that lambda to re-obtain
the net effect of a block.
In order to make this work, of course, we need to have some other primitive
syntactic construct for sequencing. The one I'm considering about is {{ e1 ;
e2 ... ; eN }}.
> 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.
>
Nope. It's interpreted as a lambda which, *if* called, does nothing and
returns. That's the consistent interpretation.
> 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.
>
Yes. And as I mentioned in my note, this code is simply wrong. The only
reason to have an inner block here in C is for the sake of adding a narrowly
bounded local variable scope. If you want to do that, you should be using
LET.
In BitC, if you really feel the need, you'll be able to write:
a()
let in // note empty binding list
b()
c()
shap
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
