(Almost) everything is expression
Dmitry Soshnikov
dmitry.soshnikov at gmail.com
Fri Nov 11 10:01:49 PST 2011
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.
More information about the es-discuss
mailing list