Blocks: minimal or multiple kinds?

Herby Vojčík herby at mailbox.sk
Thu Jan 12 12:16:52 PST 2012


Oh. I feel the barrier of misunderstanding :-(

Give me one more try to get the message through.
(I'd like to have some IM or irc with you, because it would be bad to be 
misunderstood again)

I am trying to draw a line not on actual execution semantics (code blocks 
and lambda blocks are different in this), but by "inherent" nature of the 
block contents.

The code blocks is sequence of statements, variable declarations, function 
declarations, module declarations (maybe something more). Let me call them 
"imperative elements". If delimited, semicolon is used. The "inherent 
nature" of code block is to represent the linear list of actions (some of 
them simple, some of them structured) that specify the control flow of some 
code actions. I call this inherent nature "imperative".
The lambda block is sequence of "imperative elements", too. In fact, except 
|args| at the beginning, there is not structural change that makes it 
different form code block. Its "inherent nature" is imperative, too (even if 
it is parsed as expression and not run immediately. It is not the matter 
here).
A module block is sequence of "imperative elements, too. It can contain 
export keyword, but otherwise, again, no big difference, structure-wise, 
from the code block. And its "inherent nature" is also imperative. It is 
much akin to the body of <script> in web apps today (though it can be 
nested).

So I am saying here - let us define an imperative block structure and 
elements (and the structure itself is dictated by its purpose. to represent 
list of "imperative elements", that is, control-flow). Then let us say the 
all above mentioned cases of {...} (include if/then/....sub0blocks, function 
bodies, and more) are all imperative blocks.
The common structure and elements give common semantics of the block 
_contents_, but the blocks themselves are different from use case to use 
case. Nevertheless, the elements they are build from would be consistent all 
over.


And now, the object literal is sequence of member productions and method 
declarations. Let me call then "declarative elements". If delimited, colon 
is used. The "inherent nature" of object literal is to represent (unordered) 
list of data productions that specify the blueprint of a data structure. I 
call this inherent nature "declarative".
I claim that class block's "inherent nature" is also purely declarative. It 
declares the structure of the class. In declaring a class, there is nothing 
imperative (in constuctor body, yes, but it is a function body, it _is_ of 
course, imperative).

I wanted to draw a line, much more "abstraction-wise", using the "inherent 
nature" or "purpose" to define imperative blocks and declarative blocks, and 
to postulate that every {...} has only one of such natures. Not mixing them.

The good things it can bring is consistent use of the same metaphor and same 
building blocks with same meaning all over (code - list of statements  etc. 
same in all contexts; data - list of members, having access modifiers, 
possibility to declare a method, ... exactly same all over); "clarity" or 
how should I call it - the well-defined intent-separated case of use of 
{...} and last but not least, much greater possibility to enhance their 
expressive power if there will be less concerns that hybrids will exist.

In no way did I want to propose that { code } be taken as expression. On the 
contrary - each use of {...} is well categorized as either code or data, and 
its structure is then given by that.

Herby

P.S.: Do not take me by the word - I know the class needs to describe 
constructor function's members as well as prototype's member. But it has 
static keyword for it. Everything in the class which is not static is the 
description of the class' prototype. And if it is declarative, it should be 
written as declarative (object-literal way). imnsho. (if class is just a use 
case of "declarative" block group, then it get all the goodies automatically 
and they would be guaranteed to work same way as they do for object literal 
(I mean access modifiers, method declaration syntax, and there can be more). 
No special cases (except static) which is in one place but not in another.

P.P.S.: I am not disclosing that this was created in my mind while I was 
working on that other thing (which is in "RFC: Empowered data" thread") but 
a) I see how powerful vistas does this open b) I (by feeling only) think 
that overall having such clear imperative / declarative distinction on one 
side and consistent use of building elements within each group is a Good 
Thing (tm). (as I am writing it, it associated me "loose coupling" and "high 
cohesion").

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

> I wasn't talking about unifying code and data blocks (here).

Ok, I must have misread. I thought you wrote "All of: - code block -
module block* - lambda block** could be use cases of one type of block".
I don't see how that is possible given what I wrote in reply.

Both syntax (|| is required for a block-lambda empty parameter list) and
semantically (delayed evaluationg until invocation; completion reform
also), block-lambdas and blocks are not "one type of block".

/be 



More information about the es-discuss mailing list