Delurking comments on the 0.1.5 specification

Jim Mayer jim at pentastich.org
Sat Apr 3 12:11:23 PDT 2010


On Sat, Apr 3, 2010 at 11:57 AM, Neal Gafter <neal at gafter.com> wrote:
> On Sat, Apr 3, 2010 at 8:50 AM, Jim Mayer <jim at pentastich.org> wrote:

>>
>>    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?

expression-lambda is transparent with respect to expressions and
returns a result value.
transparent-block is transparent and returns a result value (the value
of the trailing expression).  It was intended to be like the body of a
ClosureLiteral in BGGA (the final "expression" should have been
optional).

>
>> 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.
>
I was just trying to show mappings from some of the examples I've
seen.  The first two are from the draft spec.  The third is from the
talk at Google you mentioned earlier.

Just as an example, all of the following would be equivalent (but the
language would only support one):

    expression-lambda(int x)(transparent-block { if (x < 5) break; x *
3 }) // in "ugly" non-syntax

    #(int x)[[ if (x < 5) break; x * 3 ]] // parameters as in draft spec syntax
    {int x => if (x < 5) break; x * 3 ]] // BGGA syntax.
    [[int x ==> if (x < 5) break; x * 3 ]] // BGGA syntax with more
visually distinct delimiters.

In the first case, I could imagine making "[[statement* expression?]]
a shorthand for "#()[[statement* expression?]]", so people could write
things like:

To my eye, the "[[" construct is significantly more visible than a
single bracket would be. Comparing:

    #(int x)[return x+1;]
    #(int x){return x+1;}
    #(int x)(x+1)
    #(int x)[[x+1]]
    {int x ==> x+1}
    [[int x ==> x+1]]

I find the first two wayto easy to mix up.

The BGGA parameter declaration syntax, and the use of "==>" helps make
the literal form much more visually distinct and probably composes
better.  My concern is that it will be a very hard sell to the
community just because in the C/C++/Java tradition parameter lists are
expected to be bracketed by parenthesis.

Design for usability is hard and outside of my comfort zone.  I'd be
tempted to try to find an industrial designer and a typographer or two
and see what they say.  That's actually a serious suggestion!

-- Jim


More information about the lambda-dev mailing list