Semantics and abstract syntax of lambdas

Lex Spoon spoon at google.com
Thu Dec 18 06:45:20 PST 2008


On Wed, Dec 17, 2008 at 9:42 PM, Yuh-Ruey Chen <maian330 at gmail.com> wrote:
> Unfortunately, "{" in expression context is taken by the object literal.
> However, I think "{{" would be feasible. That is, if the parser is in
> the expression context, if it encounters two '{' tokens in a row, it
> could treat it as you defined above, e.g.
>
> val = {{ val x = 1; val y = 2; x + y }}

Cool.  I will confess this particular syntax will likely invite
confusion about when to use { } versus {{ }}, but maybe that's not
true, or maybe there is some other light syntax that can be dreamed
up.


>> A light syntax for this kind of expression would immediately solve the
>> issue with lambdas that result in expressions.  This, in turn,
>> honestly seems important for lambdas to really be convenient to use.
>> (Granted, lambdas being convenient is much less important than having
>> them available at all.)
>>
>
> Do you have an explicit syntax in mind?
>
> I can turn this around and say that with really convenient lambdas,
> expressions of the form you discuss would be trivial, e.g.
>
> val = fn { val x = 1; val y = 2; x + y }()

That's very helpful, though it does seem roundabout.

It presupposes that lambdas take multiple statements, of course.  I
guess I'm saying that the one-expression version of lambda can lead to
ultra-tight code when it applies, so it's a pity to give it up.
However, with a light syntax for block expressions, the language can
make lambda be one-expression but programmers can still easily write
multi-statement lambdas.  For example:

x => x+1
x => {{ var y = x+1; y*2 }}


The former is about as tight as can be, while the latter seems fine as
a multi-statement syntax.

-Lex


More information about the Es-discuss mailing list