Hi,
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
structured)
(this would include code block, function body, module and lambda block)
- declarative ones (list of data productions, colon delimited and/or
structured)
(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
construct.
Herby
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: [email protected]
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
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
