Search results for:

Per the standard, the condition in loops is an Expression, but Espruino evidently parses it as AssignmentExpression, disallowing the comma operator. This is particularly painful contexts like

while (x = costlyAccessor(i++), p(x.a, x.b)) …;

Minimal reproduction:

>while(0,0);
Uncaught SyntaxError: Got ',' expected ')'
 at line 1 col 8
while(0,0);
       ^
>for(;0,0;);
Uncaught SyntaxError: Got ',' expected ';'
 at line 1 col 7
for(;0,0;);
      ^
>do;while(0,0);
Uncaught SyntaxError: Got ',' expected ')'
 at line 1 col 11
do;while(0,0);

Oddly, if and switch have no such problem.

This may be a flaw in the Espruino documentation, then—it says there that the reason labels are not implemented is that they are bad practice, not because of the implementation strategy.

My particular use case is of this form:
search: for (…) for (…) if(…) break search; // found it!

One could of course throw an exception, use “continue” variables, or any of a number of other solutions; they're all to varying degrees confusing or inefficient, and I just wondered what the received idiom is.

Espruino apparently does not implement labels because “they're generally considered bad practice”. Really? Goto is (still) broadly considered harmful, but JS does not provide goto; its labels are used for multilevel breaks (and continues), a feature that repairs the relative uselessness and occasional opacity of C's implicitly targeted break statements. It seems a little weird to implement break (which has also been argued against by control flow purists, though I think received opinion by now is that they were arguing more out of a desire to simplify their control flow analysis algorithms than any true readability problem) and not label.

Anyway, I don't really mean to rant about language design philosophy, especially over a feature that I wouldn't notice was missing if it hadn't already been in the spec, but what's the recommended alternative on this platform?

Apparently whenever an inner arrow function has a parenthesised parameter list, a parse error is thrown. This is a minimal reproduction; real code is likewise affected:

In the REPL of the Bangle emulator:

>x=>(y)=>0
Uncaught SyntaxError: Got => expected EOF
 at line 1 col 7
x=>(y)=>0
      ^
>

But per https://262.ecma-international.org/12.0/#prod-AssignmentExpression

AssignmentExpression: … | ArrowFunction | …;
ArrowFunction: ArrowParameters => ConciseBody;
ArrowParameters: BindingIdentifier | CoverParenthesizedExpressionAndArrowParameterList;
BindingIdentifier: Identifier | …;
CoverParenthesizedExpressionAndArrowParameterList: ( Expression ) | …;
ConciseBody: [Lookahead ≠ {] ExpressionBody | …;
ExpressionBody: AssignmentExpression;

The parser is thus not supposed to commit early to whether “(…” starts an expression or an arrow function, whether or not we are already inside an arrow function. And, indeed, other interpreters I've tried have no such problem.

There is of course a workaround, to use full function syntax for the inner function, but (and here I cannot intuit what is going wrong), parenthesising the inner function does not work, producing any of a variety of strange errors.