Blocks: minimal or multiple kinds?

Herby Vojčík herby at
Thu Jan 12 11:20:55 PST 2012


I wasn't talking about unifying code and data blocks (here).
I was pointing to the fact that there seem to be lot more (different as to 
syntax and as to general abstraction).
I was asking if it would be possible to postulate that there are only two 
"higher level" kinds of blocks:
- imperative ones (list of statements, semicolon delimited and/or 
   (this would include code block, function body, module and lambda block)
- declarative ones (list of data productions, colon delimited and/or 
   (this would include object literal and class)

This is so the code/data line is sharply drawn (_unlike_ your example, I 
proposed the opposite) and all syntactic elements and their general 
underlying semantics (possible statements for imperative, member modifiers 
for declarative, ...) be defined in one place and consistently used in all 
use cases.

In other words  b = { S(); T(); }; would be syntax error because { S(); 
T(); } cannot be parsed in expression context (as it is today), the same for 
other examples.

My main point is to not have "hybrid" curly blocks (like class is today), 
but define one for code and one for data, give it rich expressivity (like 
allenwb is doing to object literal) and consistently define - this is code, 
this is data, this is code, this is data for this or that language 


P.S.: The other proposal I had does something like unifying them, but in 
completely different way, not the one in which your examples are 
problematic. None of them is problematic there, but it is on the other 
thread, anyway. Here I only wanted to here about "either code or data, 
nothing in between" idea.

-----Pôvodná správa----- 
From: Brendan Eich
Sent: Thursday, January 12, 2012 7:35 PM
To: Herby Vojčík
Cc: es-discuss at
Subject: Re: Blocks: minimal or multiple kinds?

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 

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


More information about the es-discuss mailing list