Thanks -- gists and github's discussion support are good for detailed syntax snippet back and forth, now that you mention it. Better than plain old mail for fast and focused interaction.
The <> for formal parameter lists won't fly in committee, I'm pretty sure. Not just due to E4X but because of the mismatch with () for actual parameter lists. Also, Allen is using <> in a different context, object initialiser meta sections, but close enough for confusion: http://wiki.ecmascript.org/doku.php?id=strawman:obj_initialiser_meta This is still a strawman, but <> and [] are both not attractive for multiple reasons as formal parameter brackets, so I see long odds. /be On Mar 26, 2011, at 8:09 PM, Kevin Smith wrote: > 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
