(Almost) everything is expression

[François REMY]

I didn't read your first mail, I've to acknowledge. That doesn't change the 
fact the sample was reinventing the wheel.

BTW,your samples all suffer from a big ambuiguity that I think is 
unresolvable.

    let a = if (foo) {
       print('a is foo');
       foo;
    } else {
       // do some longer stuff
    };

How do you know "foo" is an expression that should be assigned to "a" and 
that "print('a...')" is not?

In ECMAScript, each statement returns a value. There's no way to find out if 
the statement is a "normal" statement or a "value" statement. To my 
understanding, there's no.

    let a = try {
        if(test()) {
            translate("test was true")
        } else {
            translate("test was false")
        }
    } catch(ex) {
        translate("test has raised an exception")
    }

Secondly, is it worth modifying the UA's compilers and JS syntax? What's 
what you gain, in terms of readability, in terms of facility, ... ?



PS: I don't know what is the "do" syntax you reference but I guess it solves 
the ambiguity problem by creating a kind of "block lambda". Value statements 
can be recognized by a "return" statement inside the block.

    let a = do {
        if(test()) {
            return translate("...");
        } else {
            return translate("...");
        }
    }

In such case "do { ... }" is just a sugar for (function() { ...})(). It 
could be used to make more beautiful the "module" pattern used in many codes 
now.




-----Message d'origine----- 
From: Dmitry Soshnikov
Sent: Friday, November 11, 2011 10:42 AM
To: François REMY
Cc: David Herman ; es-discuss Steen
Subject: Re: (Almost) everything is expression

On 11.11.2011 13:26, François REMY wrote:
> <aside note>
>
>    let x = q ? 10 : 20;
>
>    Why we're reinventing the wheel here is up to me.
>
> </aside>
>

I noted it in the initial letter. Yes, we have the sugar for this
particular case for years (the ternary operator). But also with this I
mention that it doesn't allow _conveniently_ handle complex bodies of
consequent and alternative nodes of an if-expression. Please re-read my
initial letter.

Once again, the idea is to have _in addition_ for all the statement
parts the same expression parts (not only for if-statement, so sorry, I
don't buy your "reinventing the wheel").

And since this is exactly the _addition_, but _not the replacement_,
it's still possible to use statement forms (w/o explicit semicolon). But
if you need an expression form, use it. The same as with FD and FE.

Dmitry.

> -----Message d'origine----- From: Dmitry Soshnikov
> Sent: Friday, November 11, 2011 8:54 AM
> To: David Herman
> Cc: es-discuss Steen
> Subject: Re: (Almost) everything is expression
>
> On 11.11.2011 11:43, David Herman 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.
>> It's a serious price, though. Today if I write:
>>
>>      if (q) { ... }
>>      else { ... }
>>      (f())
>>
>> then ASI kicks in after the else body. If we make if-statements into 
>> expressions, then either the above becomes a single expression, which is 
>> a serious and subtle backwards-incompatible change, or we define 
>> lookahead restrictions on ExpressionStatement, and introduce a 
>> refactoring hazard:
>>
>>      x = if (q) { ... }
>>          else { ... }
>>      (f())                 // oops, this is now a parameter list on the 
>> RHS of the assignment!
>>
>> I'm not positive, but that seems like a serious issue to me.
>
> Yes, all this relatively true, but personally I don't see the big issue.
> In practice we already have such a case e.g. for FD (function
> declaration) vs. FE (function expression).
>
> The former doesn't require semicolon, the later does. Though, in the
> later case (FE), today most of programmers put explicit semicolon to
> avoid problems with scripts minimizing. From this viewpoint it's not a
> big price, since even now the programmers are already used to such cases.
>
> Regarding old code it's also not the issue since there is no such old
> code, it's a syntax error. And even if a user will refactor code (to
> make it look shorter and elegantly), she should be aware about this case
> (again -- just like with FD and FE -- users are aware about it):
>
> Was:
>
> var x;
>
> if (q) {
>   x = 10;
> } else {
>   x = 20;
> }
>
> Becomes:
>
> let x = if (q) {
>   10;
> } else {
>   20;
> };
>
>>> Nope, have to think more on this...
>> You might want to take a look at this:
>>
>>
>> http://wiki.ecmascript.org/doku.php?id=strawman:block_vs_object_literal
>>
>
> Yep, I've seen it before briefly; will check it more precisely later,
> thanks.
>
> Dmitry.
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss