(Almost) everything is expression

[Dmitry Soshnikov]

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.