That hash symbol

Kevin Smith khs4473 at
Sat Mar 26 20:14:49 PDT 2011

I've put examples of real world code chock-full of anonymous function
expressions in both leading-char (#) and angle-braketing styles here:

Feel free to continue this discussion on that page, if inclined.


On Sat, Mar 26, 2011 at 10:44 PM, Brendan Eich <brendan at> wrote:

> 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.
> /be
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list