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: [email protected]
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
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
