Block lambda is cool, its syntax isn't

Jon Zeppieri zeppieri at gmail.com
Thu Jan 12 16:39:41 PST 2012


On Thu, Jan 12, 2012 at 7:11 PM, Allen Wirfs-Brock
<allen at wirfs-brock.com> wrote:
>
> On Jan 12, 2012, at 3:41 PM, Jon Zeppieri wrote:
> ...
>
> With the grammar François is suggesting, this would be a syntax error
> (I think), since the body of a block lambda is a StatementList_opt.
> The {| syntax, on the other hand, can accommodate block lambdas as
> expression statements, though, given another token of lookahead
> (again, I think).
>
>
> With two token look-ahead a | BlockLambda could be allowed at the head of a
> statement, but it still would not enable unparenthesized object literals at
> the head of a statement.  It seems like a cognitive burden to allow one  but
> not the other.  A simple "{ at the start of an expression statement must be
> parenthesized" rules seems easiest to learn and remember.
>
> Allen
>

That's a good point, but I think that unparenthesized block lambdas
might be worth this complication. I hadn't considered object literals,
at all, while writing the previous message, and I don't think that was
simply an oversight. Object literals and blocks have a similar syntax
but dissimilar meaning. Block lambdas, on the other hand, are
semantically kinda-sorta like blocks. You don't need to parenthesize
nested blocks in JS code. (In fact, you can't.) That leads me to
expect unparenthesized block lambdas.

I guess it depends, to some extent, whether you think block lambdas
and object literals have more in common with each other (both being
first-class values) than block lambdas and blocks do (both being lists
of statements).


More information about the es-discuss mailing list