I think you are missing something important:
...; { S(); T(); }; ...
shows a block. It is eagerly evaluated in succession after the elided
code to the left.
...; {|| S(); T(); }; ...
is a block-lambda, which in this example is useless -- but crucially, it
is not invoked without suffixing (), as with any callable object.
Now, to make the examples more useful, suppose we could support blocks
as expressions without making an ambiguous or overcomplicated grammar:
...; b = { S(); T(); }; ...
given a declared b would mean what? It should not create a callable
object that must be invoked to evaluate S(); T(), because that breaks
symmetry with existing block-statement meaning, e.g.
if (C) { S(); T(); }
There's no () to invoke the consequent block -- if C evaluates to true
then control flows to the then clause which eagerly evaluates the block
statement.
There are other problems with unifying block and object literal syntax
(never mind semantics), but this one is enough to kill the idea. Blocks
as braced statement lists are not a single thing in JS, even in ES1:
function bodies are not block statements (consider var hoisting).
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
