Blocks: minimal or multiple kinds?

[Herby Vojčík]

Hello,

what is the policy and projected outcome (in spec, grammer-definition-wise 
as well as described-abstraction-wise) of the diiferent kinds of {...} 
blocks?

There is plain code block, an object-literal, module block, class block, 
lambda-block. Maybe I missed some use case.

My question is whether will all of these blocks presented as a separate 
concept, each with its own rules; or whether there is more a wish of minimal 
system of {...} blocks where number of different kinds/abstractions is kept 
to a minimum a each of aforementioned use is presented as only a use case of 
a more general concept.

I feel having many kinds of blocks, each having their own rules makes the 
language complicated and that having only a few kinds of blocks is enough.

For example, this shows two clearly distinguished abstractions/syntaxes of 
{...} can be enough for the whole language:

All of:
  - code block
  - module block*
  - lambda block**
could be use cases of one type of block - the code (imperative) block. An 
imperative block should have its own structure and rules (statements, 
var/function declarations. automatic semicolon insertion, sub-code-blocks, 
...) and above mentioned items would only be special cases of it (see 
footnotes). But all of them would share everything that is common for 
imperative block - by design. So it can be defined once and used for every 
case, without change.

All of:
- object literal
- class block***
could be use cases of one type of block - the data (descriptive) block. A 
descriptive block should have its own structure and rules (properties, 
const/non-enum/... modifiers, method definition syntax, ...) and and above 
mentioned items would only be special cases of it (see footnotes). But all 
of them would share everything that is common for declarative block - by 
design. So it can be defined once and used for every case, without change.

I think this would bring less confusion of what kind of construct is 
supported where and the borderline will be drawn very clearly (possible for 
future {...} constructs, as well).

Herby

* can contain export keyword; appears in context of module keyword
** has |args| at the beginning; appears in expression context
*** can contain static keyword; appears in context of class keyword