Delurking comments on the 0.1.5 specification

[Jim Mayer]

On Sat, Apr 3, 2010 at 11:06 AM, Neal Gafter <neal at gafter.com> wrote:

> The most important thing is to ensure that lambda expressions (that
> could be extended to support transparency) don't look anything at all
> like method definitions so as to reduce the confusion.  As for
> bridging the gap, one approach is to have two forms of lambda
> expression: one with curly braces (and therefore somewhat similar to a
> method definitions) and one without (and therefore less similar).
> That's the approach taken in CfG; see
> <http://www.javac.info/closures-v06a.html> and
> <http://www.javac.info/closures-v06b.html>.  You previously rejected
> this approach because you thought that expression lambdas are pure
> syntax, but expression lambdas are transparent while statement lambdas
> are not.

I'm sorry.  I didn't mean to reject an expression syntax (which I like
for a lot of reasons).  I was noting that, in the context of the
current draft specification (which doesn't have a way to include
statements in expressions), it does seem to be syntactic sugar.
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.

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(); }))

-- Jim