Parser errors in arrow functions (2v10.90 Bangle emulator)

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.

Thanks for this - I've just filed an issue at https://github.com/espruino/Espruino/issues/2067

It looks like the parser is attempting to parse an AssignmentExpression as the body of the first arrow function - but I'll have to step through to see why it's not picking up the second one. It might be due to an optimisation that tries to skip over blocks when they're not being executed.

Worth noting that x=>{ return (y)=>0 } works fine.

...already commented in the other thread - Conditions in loops processed as AssignmentExpression, should be Expression what I 'feel' about these things... and I notice, @Gordon, you use the same 'trick' for making the parser happy as I do for the lint: pack it into parens. Now, if the parens get removed - by the minifier - it stays an issue if such constructs are actually of practical use.

Espruno - as interpreting off of the source without creating byte code ahead of execution - and that would still be the case for the planned JIT compiling down into (thumb)assembler code - should not be bothered and slowed down by a theoretical or 'by the letter' exercise that has shown not to buy/cut me a single slice of bread (hout mer ke Schibe Brot abb) to secure my going.

Well, but here's the thing: how can a person write code for this beast if it doesn't follow the spec and doesn't provide any guidance for where it is going to diverge? It's not helping anyone if we have to write and constantly refer to a cheat sheet of arbitrary divergences from even the simplest parts of the language design.

Don't get me wrong, I completely understand the idea of a motivated language subset, but arbitrarily outlawing a => (b) => x while allowing (a) => b => x, or forbidding while (a = b, c) while allowing if (a = b, c), what's that even for? Either these are bugs (and, with several language implementations under my belt, they seem more likely to be typos in the parser source than anything else), or some detailed documentation is needed so that users can know what is going to work and what is not and develop an intuition for why.

As to why I'd appeal to the ECMA spec, it's not demented legalism on my part, it's that I've already noticed that people get yelled at if they don't. Indeed, it happened to me today—I'd assumed that everyone knew what the comma operator does in C-family languages, but apparently chapter and verse is required.

@user135362, get your point... up to the term of 'arbitrarily'... - it's not like a newbee trowing darts at a (language element) tag cloud to determine gaps for fooling around with the user. I experience the decisions are well thought end-2-end. As much as I like to not have to be aware of exceptions, Espruino is so exceptional that the few exceptions do really not bother me. After all, it is a package and I get in its completeness so much that the few bread crumbs that (were made to) fell of my plate prevent me to get too fat... for sure not hungry (I like the @hungryforcodes user name!).

The ECMA spec is great and I applaud - and love - the care takers of especially version 6, Allen Wirfs-Brock, who, together with Rebecca blessed us with one of the most powerful but still - by every ones standard - easy to understand CRC method or technology for describing formally how things work in the real world and at the same time are solid and very suitable base for implementing software reflecting these workings.

As a great invention and contribution C is, was and still is, some of the community have moved on from the parens mess... but the majority of it the community - I'm part of that crowd - has a hard time for moving on to a more advanced (coder) life. If I could have even slightly influenced the choices Brendan Eich made when blessing us with JS, it would have been this: leave the C and paren family syntax for the way more advanced and readable Smalltalk syntax that does not overuse the parens, after all JS 'abandoned' many other 'good' things. In st, the parens have still great power and do what they do best: define precedence... in expressions. Even though I had a very hard time to get what the st-80 bunch tried to make understood, I felt it as a real progress after having toiled around with practically all 'languages and their dialects' common at that time. On the other hand, I'm sure - and hope -that Brendan Eich was making a very conscious decision about what syntax to pick... because after all, he could have ended up with another acceptable (G)ML/XML dialect, because already living in a great and successful one, such as the (X)HTML. Brendan Eich chose his battles wisely to introduce successfully the 'new' he wanted, and compromise on something not worth to die for.

Regarding (X)HTML: Unfortunately - or fortunately? - the X had no chance, since too much content had been created and it would be foolish to ignore it and lose the wealth I presents to these days (that's why I consider the browsers to be of the most complex and powerful SW pieces in existence.

Expecting and enabling meaningful backwards compatibility is useful: What would you say if you all printed matter would be declared as not be readable anymore. CDs - even the black vinyls - not playable anymore, paintings of the Sistine Chapel not viewable anymore and the building itself not visitable anymore, and on an on,... just because we are about to master comprehensive digitalization incl. virtual reality (and to express it seasonal: live a life of 'zoom')?

That would be really sad and make the world an even more depraved place that it already is.

Therefore I still like to read C and related but also enjoy the things that came after it and the things after those, and on and on.

I mention C not because I think its decisions are especially defensible—with all due respect to the Bell Labs crew for what they accomplished, even at the time it seemed haphazard (given that the valiant example of Algol68 was already available!)—but because, for good or ill, the brackets, the operators, and the control syntax are all inherited from it, and one of my original bug reports was about the interaction of these three. Specifically, is there any justification, any non-arbitrariness, to suddenly treating the conditions in while loops as syntactically distinct from other control construct conditions, at odds with tradition, ECMA, naive expectation and (I strongly suspect) efficiency of implementation? Sorry, I can't see it.