(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

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

It even sounds and specifies that the value of `foo` is the result of 
`exec`ution of the block.


More information about the es-discuss mailing list