That hash symbol

Brendan Eich brendan at
Sat Mar 26 19:44:23 PDT 2011

On Mar 26, 2011, at 6:44 AM, Wes Garland wrote:

> On Sat, Mar 26, 2011 at 2:33 AM, Brendan Eich <brendan at> wrote:
> On Mar 25, 2011, at 8:45 PM, David Foley wrote:
> > My response was simply this : assuming normative scope in conversational tone, that I would welcome is a venue where 
> end users (engineers and architects as well as scripters) could contribute to the developer experience of using JavaScript
> I was going to suggest comp.lang.javascript, but I just had a look and it seems to have been taken over by DOM questions and spam.  David, why don't you start an "ES Tech" group or something, and ban questions which aren't related to JS? (Copy your charter from comp.lang.c, maybe).  Announce it here, and I will subscribe. Probably even participate.

This es-discuss group sounds exactly like that "ES Tech" group -- why make a new one?

If there's too much noise in any group, new or old, the group becomes useless. Asking for some simple ambiguity checks before posting syntax strawmen, and pleading to avoid one-line followups that overcite, etc. is *not* "wrath". It's part of the well-known netiquette standard, but not enforced much these days.

Hence the decline of USENET and NNTP, the rise of stackoverflow and the like. Still a lot of noise in all the reddits, slashdots, etc. Voting/ranking can help but cliques do game the system.

For "ES Tech", let's use es-discuss. If someone thinks I called them a name when I didn't, that's just bad on them. If I was rude, bad on me. We can patch things up and move on.

And to be fair, the JS grammar is subtle enough that it's fine to propose somehting that *might* work, only to have grammarians debug it.

So don't let me rain on anyone's parade, but please don't shoot entirely from the hip. Read a bit on parsing and study the grammar, or just consider whether what you propose is indistinguishable from what is already a valid expression or expression followed by a statement.

> Non leading-char solutions have the disadvantage of using some other kind of bracketing -- e.g.  `a,b { return a + b; }`

This is ambiguous too. A comma expression followed by a block (if in an outer function, the return is legal).

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).

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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list