statements that could be expressions?

Brendan Eich brendan at mozilla.com
Thu Jun 2 20:12:23 PDT 2011


On Jun 1, 2011, at 5:52 PM, Waldemar Horwat wrote:

> On 06/01/11 16:07, Peter Michaux wrote:
>> Could some of JavaScript's statements also be allowed as expressions?
>> 
>> In Perl there is the common idiom when opening a file
>> 
>>   open F, "<  $f" or die "Can't open $f : $!";
>> 
>> In JavaScript could "throw" be an expression?
>> 
>>   f() || throw 'f failed';
>> 
>> Could JavaScript's "if" become an expression? (I know JavaScript the
>> ?: operator but this is just a for example.)
>> 
>> Could a Block statement also be an expression like Scheme's "begin"?
>> 
>> Peter
> 
> Theoretically it's possible to allow statements as expressions, but you run into a number of practical problems:
> 
> - Precedence inversion:
> 
> a = if (b) c
> 
> So far so good.  However, the substatement of an if can also be a comma expression, which causes trouble:
> 
> a = if (b) c, d

The problem here, I think, is comma expression. But commas are useful instead of semicolons for sequencing sub-expressions.

In this light, could we avoid precedence inversion and block as expression by allowing many statements as AssignmentExpression-precedence expressions?

AssignmentExpression :
    ...
    KeywordStatement

where KeywordStatement is as at http://wiki.ecmascript.org/doku.php?id=strawman:paren_free.


> Also, what should be stored in a if b is false?  You can argue between false, null, and undefined.

http://wiki.ecmascript.org/doku.php?id=harmony:completion_reform favors undefined. And that is falsy enough for the common cases.


> - Conflict between blocks and statements:
> 
> a = {x: while (x) { ... break x;}}
> 
> is either an object initializer or a block containing a labeled while statement.

http://wiki.ecmascript.org/doku.php?id=strawman:arrow_function_syntax based on feedback from Jorge here on the list mentions a block that cannot start with a label. Two-token lookahead restriction, why not?


> - Semicolon insertion:
> 
> return
>  if (longcondition) {
>    ...
>  } else {
>    ...
>  }
> 
> will not do what you want.  The entire if is dead code.

This is a bug with return's restricted expression-returning production anyway. We talked about fixing it with a dead-code error but that is a bit of a higher bar for implementors. The last time we talked about this was 2008, IIRC. Time to revisit?

/be


More information about the es-discuss mailing list