I've put examples of real world code chock-full of anonymous function expressions in both leading-char (#) and angle-braketing styles here:
https://gist.github.com/888867 Feel free to continue this discussion on that page, if inclined. khs On Sat, Mar 26, 2011 at 10:44 PM, Brendan Eich <[email protected]> wrote: > On Mar 26, 2011, at 6:44 AM, Wes Garland wrote: > > On Sat, Mar 26, 2011 at 2:33 AM, Brendan Eich <[email protected]> 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 >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
