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
