That hash symbol

Bob Nystrom rnystrom at
Tue Mar 29 15:30:47 PDT 2011

> C#, CoffeeScript, and other languages use -> to link a formal parameter
> list to a function body, which requires bottom-up parsing in general (with
> comma as operator, as JS, C++, and C have; plus Harmony's destructuring and
> default parameter value proposals).

I'm not a parsing expert, but isn't destructuring just as hard to parse
top-down as => for functions would be? Given:

    { a: b, c: d } =

A top-down parser will go up to "=" thinking its parsing an object literal.
Then it hits the "=" and have to either backtrack, or just transform the
object literal AST into a destructuring pattern. Then it can proceed on its
merry way.

Wouldn't => work the same way?

    (a, b) =>

It parses "(a, b)" thinking it's a grouped comma operator (not exactly a
common expression FWIW), then it hits "=>" realizes it's a function
parameter decl, and then either backtracks or just transforms the left-hand
AST into a param decl.

I understand this list isn't "teach me the details of the JS grammar", but
it isn't obvious to me why an infix function syntax is any harder than
destructuring as far as parsing performance is concerned. Empirically, I'd
expect it to be less of an issue because the comma operator is so rare and
parameter declarations tend to be short. Is it because there are things that
would be valid in a parameter declaration that are *not* valid expressions?

- bob

> Requiring bottom-up parsing has bounced off of implementors in the past,
> and with JavaScriptCore switching from a Bison grammar to a top-down
> hand-coded parser, I expect it will again.
> I don't find syntax like this clear from a coder's POV, and there is the
> re-tooling issue with highlighting editors and the ability to trivially
> transform between the styles for faster adoption and old code minification
> -- while these issues certainly shouldn't be deciding factors for TC39 it is
> nice that leading-char lparen...rparen makes most of them go away.
> That's the idea. We need to keep this simple or it will probably fall
> apart, either due to ambiguities, or implementors balking at too much
> complexity in parsing with more power than top-down parsers have.
> /be
> _______________________________________________
> es-discuss mailing list
> es-discuss at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list