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