On 11.11.2011 20:36, Brendan Eich wrote:
On Nov 10, 2011, at 11:07 PM, Dmitry Soshnikov wrote:
Brendan and Dave mention explicit semicolon. Yes, it's seems so by the grammar
(though, have to check more precisely), but it can be acceptable price.
No, it is a runtime incompatibility that shifts meaning, without errors.
switch (x) { case 1: (function (){return 42}); break; default: (function
(){return 99}); }
(a[i].b()).c(d)
The switch is now the callee expression in a call taking one actual parameter,
a[i].b().
The same can happen with leading [, unary +/-, and / as regexp delimiter -- any
lexeme that can both start a statement and continue an expression.
If we accept expression forms as the _addition_, I don't see the issue
here. In this case, switch shouldn't be treated as a special expression,
but should behave as the before.
If in contrast switch stands in the expression position, then it returns
its evaluated result.
It's just like FD and FE -- the later is determined only by the position
at which it stands -- if a function stands at the expression position,
then it's a FE, otherwise, it's FD. The same is here.
P.S:
Regarding Dave's `do { .. }` -- we may omit `do` and just evaluate the block.
let a = {
print('doing stuff');
100;
};
It's of course seems ambiguous with an object initialiser (at first glance),
but it's only at first glance. Obviously there is a code inside to evaluate.
I worked on this, based on ideas from Breton Slivka and Doug Crockford. Please
see
http://wiki.ecmascript.org/doku.php?id=strawman:arrow_function_syntax
and
https://mail.mozilla.org/pipermail/es-discuss/2011-June/015568.html
Yup. I of course read before this proposal. And it's pity it's not
approved, I support them, so of course the problem with parser should be
considered, I agree (moreover, if you look the archive for a one year --
I myself proposed arrow functions for ES, when you was against; now you
proposed them yourself).
This is not going to fly in a grammar that we validate using LR(1) parsing.
Block-lambdas require {|| at least to defer evaluation until invocation,
whereas any block-expression would be immediately evaluated. This could be a
point of confusion.
How that? Block evaluates at runtime stage, no on entering the context.
When reach it, then eval. Or do I miss something? I see it by the logic
as just a sugar of immediately applied function (w/ some optimizations
of course):
var foo = {
// do stuff
100;
};
is a sugar of:
var foo = !function() { return 100; }();
Both are executed differed, at runtime.
Altogether, this says Dave's 'do' proposal is better because EIBTI.
Don't forget, sometimes *too explicit* is a "syntactic noise".
If we can achieve more elegant way, I'm sure we should use it. If we may
omit this useless and ugly empty pipes || in foo = {|| ...} then let's
omit it. If we though can't do this, let's still search the alternatives.
And about do { ... } -- yeah, it's fine, though I'd replace it with e.g.
exec { ... } for not to be ambiguous with do-while block.
var foo = exec {
// do stuff
100
};
It even sounds and specifies that the value of `foo` is the result of
`exec`ution of the block.
Dmitry.
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
