Semantics and abstract syntax of lambdas

Lex Spoon spoon at google.com
Wed Dec 17 12:47:09 PST 2008


On Mon, Dec 8, 2008 at 4:08 AM, Yuh-Ruey Chen <maian330 at gmail.com> wrote:
> Jon Zeppieri wrote:
>> So, unless people want to expand the expression grammar significantly,
>> I think the expression body is a nonstarter.
>>
>
> How feasible would it be to make JS a pure expression language? That is,
> can the language be modified to allow things like:
>
> x = if (a)
>    b;
> else
>    c;
>
> first_test_prop = for (let p in o)
>    if (/^test/.test(p)/) {
>        p; break;
>    }

There's a simpler way to expand the expression language dramatically.
I'm not sure why so few languages include it, and I'd be curious if it
has been considered for Harmony.

The technique is to include an expression form which contains a
sequence of statements followed by an expression.  In Scala, the
syntax looks like this:

   { statement1; statement2; result_expression }

So you can do things like:

  { val x = 1; val y = 2; x+y }

The result would be 3.  I'm not sure what the best syntax would be for
JavaScript, but surely there is room somewhere.

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.)

There are side benefits to this expression form, too.  It means you
can much more frequently replace a function call by the function's
contents, even when the function appears in an expression-only
context.  For example, you can more frequently inline the g() in
f(g()).  This makes programmers more dextrous, because their rewrites
can be more localized.  Further, it has obvious application for an
optimizing compiler such as GWT's....


-Lex


More information about the Es-discuss mailing list