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
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
