Sorry, thought about it
more and I'm raining on your (and dherman's) parade :-(.
In an _expression_ but not statement context,
... { (x)
e; }
is already a valid JS program if e begins with (, [, +, or - (the last
two intended as unary operators but becoming binary).
Note that | bracketing avoids this problem. In no case can JS of any
extant version have a legal sequence {|.
But because {( is already allowed, what comes after the closing ) can be
the continuation of a parenthesized _expression_.
Even if you don't buy my "better to look different because not function"
argument, this tilts the balance.
/be
Am I wrong
if I say there not a bigger issue with block lambda than with the
current object notation on the matter?
Please continue :-).
I mean, does that code mean anything useful?
function() {
{|a,b| a+b};
}
(You need a name for that function if it is a declaration, and from the
context you show, it is.)
Does this perfectly valid JS mean anything useful?
function f() {
(function (a, b) { return a + b; });
}
Nevertheless, it is legal. JS follows C (not Java) in allowing seemingly
useless _expression_-statements. This can be a source of bugs. It is also
required in some cases, namely when the function _expression_ (in
parentheses) is the completion value of a Program. In such a case that
value could be the wanted result of eval or an eval-like host API.
If not (as it seems to me), it means that a block lambda will not be
used as
a statement by itself. If it's the case, it should defined as an
_expression_
only,
_expression_ is already a kind of statement, via ExpressionStatement.
Furthermore, an ExpressionStatement *already* cannot start with a left
curly brace. Please read the grammar:
12.4 _expression_ Statement
Syntax
ExpressionStatement :
[lookahead ∉ {
{,
function}]
_expression_ ;
NOTE An ExpressionStatement cannot start with an opening curly brace
because that might make it ambiguous with a Block. Also, an
ExpressionStatement cannot start with the function keyword because that
might make it ambiguous with a FunctionDeclaration.
where
there's no anonymous block to conflict the syntax.
This is the conflict you're looking for.
That
solution
has been chosen for object notation in the past. That way,
function() {
{
(a, b)
a.add(b)
}
}
That is already valid ES1-6.
Others have already replied, but the problem with redefining ( after {
without untenable newline sensitivity is it is a backward-incompatible
change.
/be
Am I wrong if I say there not a
bigger issue with block lambda than with the
current object notation on the matter?
I mean, does that code mean anything useful?
function() {
{|a,b| a+b};
}
If not (as it seems to me), it means that a block lambda will not be
used as
a statement by itself. If it's the case, it should defined as an
_expression_
only, where there's no anonymous block to conflict the syntax. That
solution
has been chosen for object notation in the past. That way,
function() {
{
(a, b)
a.add(b)
}
}
would still be an anonymous block where
function() {
asyncAction(..., { (a, b) a.add(b); } }
}
would be a block lambda as an argument of an async function. No
semantic
change for an identical syntax, in regards to strict ES5.
The case where you would like to use a block lambda as a stament can
be
resolved by adding parenthesis, like with the current object notation.
And
since I still continue to hope we'll ditch the unprefixed anonymous
block in
some future revision of ES, that very small edge case could vanish at
the
same time.
Does it seems possible/acceptable?
-----Message d'origine-----
From: Allen Wirfs-Brock
Sent: Thursday, January 12, 2012 10:38 PM
To: Thaddee Tyl
Cc:
es-discuss@mozilla.org
Subject: Re: Block lambda is cool, its syntax isn't
On Jan 12, 2012, at 1:26 PM, Thaddee Tyl wrote:
but it is ambiguous with other currently valid statement blocks
such as:
{ (a, b) + b}
or
{ (a,b)
a+b
}
Allen
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
