That hash symbol

Brendan Eich brendan at mozilla.com
Sat Mar 26 20:15:37 PDT 2011


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 <brendan at mozilla.com> 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 mozilla.com> 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: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110326/f32ba749/attachment.html>


More information about the es-discuss mailing list