Delurking comments on the 0.1.5 specification
Neal Gafter
neal at gafter.com
Sat Apr 3 08:57:22 PDT 2010
On Sat, Apr 3, 2010 at 8:50 AM, Jim Mayer <jim at pentastich.org> wrote:
> Separating the syntax and semantics discussions would highlight the
> semantic import of adding statements (with transparent semantics) to
> expressions. Or maybe the "ugly" syntax should have been for
> expressions, and could include two different forms for nesting
> statements:
>
> expression-lambda(arg...) (expression) // an expression lambda.
> transparent-block { statement* expression } // break, continue,
> return have transparent semantics.
> function-block { statement* } // break, continue are disallowed.
> return exits the function block.
Which of these is transparent and supports a result value?
> Given such an abstract syntax, we could compare "real" syntax:
>
> #(int x)(x) ==> expression-lambda(int x)(x)
> #(int x){ return x; } ==> expression-lambda(int x)(function-block
> { return x; })
> withLock(lock) { doSomething(); }
> ==> withLock(lock, expression-lambda()(transparent-block {
> doSomething(); }))
You didn't suggest a syntax for transparent lambdas. You only showed
a syntax for the special case of composing it as the last argument in
a method invocation.
More information about the lambda-dev
mailing list