That hash symbol
2011/3/25 Kevin Smith <khs4473 at gmail.com>:
As a simple matter of taste, I find the # symbol to be quite ugly and have been thinking of alternatives for shortening function expression syntax. In working with my own wonky version of promises, I continue to make the same typing error over and over again. This is something like what I mean to type: obj.doSomething().then(function(val, err) { ... }); But I find myself typing this instead: obj.doSomething().then(val, err) { ... }); The problem isn't so much the extra typing of the "function" keyword, but the profusion of parens. I'd like to suggest the following form instead. obj.doSomething().then(<val, err> { ... }); Correct me if I'm wrong, but since expressions cannot start with "<", this shouldn't present any problems for a top-down parser. Is that right?
Does this cause ambiguities with E4X ? developer.mozilla.org/en/e4x
Oh, boogers! : )
Implicit functions?
globalMethod(argument) { // implementation };
AnObject.prototype.method(value) { // whatevs };
2011/3/25 David Foley <davi.fol at gmail.com>:
Implicit functions?
globalMethod(argument) { // implementation }; AnObject.prototype.method(value) { // whatevs };
Is this a proposed syntax?
If so, in the presence of semicolon insertion, isn't this ambiguous with
globalMethodCall(argument); { // block } ; // noop AnObject.prototype.methodCall(value); { // another block } ; // noop
It's totally ambiguous.
Suggestion: do not mail syntax ideas without working through (pencil and paper, Jison/Bison/Antlr/something, or better) the grammar.
More specific suggestion: don't bikeshed function syntax without a new prefix character or a convincing top-down parsing story. If you don't know what top-down vs. bottom-up means, find out first.
Is this a proposed syntax?
No- It was an off the cuff reaction
Suggestion: do not mail syntax
Noted
Sure - no offense or time-wasting intended.
No problem -- just don't provoke Zeus to unleash the Crock-en ;-).
On Fri, Mar 25, 2011 at 11:24 AM, Brendan Eich <brendan at mozilla.com> wrote:
No problem -- just don't provoke Zeus to unleash the Crock-en ;-). esdiscuss/2011-February/012761
Perhaps there needs to be a venue where non-experts can bounce ideas and discuss points of pain with volunteering committee members to reduce noise in this venue. There is little room here for light-hearted discussion and mentoring for members of the community who have less than full-time commitment and years of experience in language design.
It's disappointing to be ostracized, but it is true. I also want to see careful and well-wrought steady progress. I remember a former decade when this discussion was impossible to follow, too many bad ideas were too thoroughly discussed, and much time was wasted.
Kris Kowal
Dunno. You were ravaged by the Crocken so you may be a bit sore still :-/.
Any list with informal/unsound syntax talk is not one I want to be on. It's not quite beer talk. It could lead to a breakthrough idea, who knows? But the cost is pretty high.
I'm not against syntax proposals here, mind you. Let's just work out the grammar a bit before launching.
Le 25/03/2011 20:18, Brendan Eich a écrit :
Dunno. You were ravaged by the Crocken so you may be a bit sore still :-/.
Any list with informal/unsound syntax talk is not one I want to be on. It's not quite beer talk. It could lead to a breakthrough idea, who knows? But the cost is pretty high.
I'm not against syntax proposals here, mind you. Let's just work out the grammar a bit before launching.
This is said and (hopefully) read by people who are currently on the list. But it might be worth saying it while welcoming people on es-discuss (on the listinfo page or welcoming e-mail after validation) so that each time someone comes in with the expectation of bringing a syntax idea, s/he can be told beforehand that s/he should start working on the grammar and bring something already solid to the mailing-list.
I haven't taken the occasion to do so yet, but I'd like to thank you for considering that an open mailing-list will be beneficial for ECMAScript as a language. Nevertheless, by doing so, you're creating a community and like every community, there are rules, conventions, expectations. It might be time to formalize these in a way or another. The WHATWG has done it on their wiki. For inspiration, I recommend reading: * wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_removing_bad_ideas_from_a_specification.3F * wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F
,
That's something I for one would welcome, and I'm sure others too. I'd like to see some traction on this
On Mar 25, 2011, at 2:07 PM, David Foley wrote:
That's something I for one would welcome, and I'm sure others too. I'd like to see some traction on this
I don't want to spend too much time on custom etiquette.
Also I don't want to be a jerk about it, but your post both bottom-cites heavily (top-citing without editing is even worse, but please trim; I nag everyone and fail myself, so again don't take this as more than a chance to restate an old USENET rule).
Another thing: you'd like to see some traction on "this", my favorite pronoun. Which "this"? If you don't like # for sharp functions, then we're back to inventing syntax. That requires some care not to walk right into (fairly well-known, but trickier due to ASI and "lack of ASI where you expected it") grammatical ambiguities.
Throwing up ideas and letting the grammarians debug them on the list is possible and might be fun but (in my view; I'm not the list moderator, just admin -- we have no moderator) it's not a good use of the list or all our time.
So: top-cite and trim carefully, avoid pronoun trouble, and try to make concrete proposals where (if they involve new syntax) you've worked through some of the consequences to avoid the obvious gotchas.
This may be too much to ask, but I'll ask for it anyway. It ought not cause a swerve into "OMG fascist list rules". But some of us old timers expect at least the old netiquette rules to apply still. Follow them and the Crocken may stay peacefully asleep.
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 without incurring the wrath of it's fathers, which appear to be more focused on the interpreter of the language rather than the thrust of it's use cases (which almost always appear to bottom out on library abstractions to solve the issues).
I really would have hoped that rather than assuming an asses POV that this list would assume the best without requirement of over-qualification.
Like it or not, JavaScript is the glue of the web. This language space has been embroiled in vendor politics since day one- end users need an effective forum to describe their requirements- that is what I was espousing. Clear enough?
You do yourself a disservice by assuming idiocracy.
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 without incurring the wrath
"wrath"? I may have failed to add a smiley, but c'mon. No wrath here.
of it's fathers, which appear to be more focused on the interpreter of the language rather than the thrust of it's use cases (which almost always appear to bottom out on library abstractions to solve the issues).
What do you mean? What library abstractions, and what issues? Please be specific.
Remember, I'm the one pushing for new syntax more than many others involved in TC39:
brendaneich.com/2011/01/harmony-of-my-dreams
I really would have hoped that rather than assuming an asses POV that this list would assume the best without requirement of over-qualification.
Skipping, I don't know how to read this and I really don't want to guess ("asses POV" meaning "ass's POV"? Who said anything about "ass" here? Yeesh.)
Like it or not, JavaScript is the glue of the web. This language space has been embroiled in vendor politics
There is no "vendor politics" in this thread, though.
since day one- end users need an effective forum to describe their requirements- that is what I was espousing. Clear enough?
No, you have not made any requirement clear. Let's take your first post today:
Implicit functions?
globalMethod(argument) { // implementation };
AnObject.prototype.method(value) { // whatevs };
Dropping function as the leading keyword makes these examples ambiguous, due to automatic semicolon insertion as Mike Samuel pointed out.
Sure, losing the heaviness of eight-letter 'function' is a goal, and we've discussed it often:
www.google.com/search?q=site%3Amail.mozilla.org+shorter+function+syntax
The ecmascript.org wiki has a strawman on it:
strawman:shorter_function_syntax
This is not going forward as-is, and the plan is to write a new strawman, but the goal of shorter function syntax is getting attention.
We spent time yesterday at the TC39 meeting not only on shorter syntax but exactly how to support better |this| handling for several distinct use-cases: inner functions that want the outer |this|, callbacks that want a certain |this|, and object methods that want the receiver when called as methods of a given (receiver) object (else possibly a default such as the outer function's |this|).
Anyway, there's more to do than fix syntax, but the syntax has to be unambiguous. That's the first requirement, before we can go further.
Kevin Smith started this thread by objecting to #, and that's fair. It's a bit chicken-scratchy. If we can find a better introductory keyword or formal parameter bracketing form, I'm game. I don't think <>-bracketing is it, not only due to E4X (who cares, right?) but mainly because that breaks symmetry with call expression, which uses ()-bracketing.
CoffeeScript uses () for formal parameter bracketing (where there are formal parameters; parameter-less functions start with -> or =>), but allows call expressions to elide the ( and ) where there is no ambiguity -- no ambiguity according to CoffeeScript's complex, evolving rules for disambiguation.
I had the chance to talk to Jeremy Ashkenas about this recently, and he does not recommend trying to graft these rules onto JS and standardize them. I agree.
So a leading character instead of 'function' still seems like the cleanest solution. Ideas other characters than '#' are welcome, since so long as they are not used in the language already (either as punctuators, operators, or identifier characters), they can't introduce ambiguity.
You do yourself a disservice by assuming idiocracy.
I did not assume anything.
(Good movie, though -- Mike Judge is great!)
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.
Kevin Smith started this thread by objecting to #, and that's fair. It's a bit chicken-scratchy. If we can find a better introductory keyword or formal parameter bracketing form, I'm game.
I like Doug's florin idea from an aesthetic POV, but I have two problems with it -- suddenly, I have to care what charset my editor is using -- but more importantly, I can't figure out how to type it on my Sun keyboard or on my Windows box. Also, what of JS which is delivered on the web using something other than unicode?
Allowing both is an interesting option, but then I remember how annoying ANSI tri-graphs were (history lesson for !brendan: not all terminals had {, C programs allow ??< instead) and realise that would be a mistake.
I, too, find #(a,b) but frankly, there aren't many lead-char solutions which aren't ugly, easy to type, and not used by identifiers (or as operators) already. What have we got to chose from? I think `@#%^&* -- none of these are measurably better than # and some are worse. Maybe you could make the point that & looks like a melted lambda. But I see no point in bike shedding over this.
Non leading-char solutions have the disadvantage of using some other kind of
bracketing -- e.g. a,b { return a + b; } -- 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.
You do yourself a disservice by assuming idiocracy.
I don't think Brendan ever assumed that this place is governed by idiots.
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.
Kevin Smith started this thread by objecting to #, and that's fair. It's a bit chicken-scratchy. If we can find a better introductory keyword or formal parameter bracketing form, I'm game.
I like Doug's florin idea from an aesthetic POV, but I have two problems with it -- suddenly, I have to care what charset my editor is using -- but more importantly, I can't figure out how to type it on my Sun keyboard or on my Windows box. Also, what of JS which is delivered on the web using something other than unicode?
Allowing both is an interesting option, but then I remember how annoying ANSI tri-graphs were (history lesson for !brendan: not all terminals had {, C programs allow ??< instead) and realise that would be a mistake.
I, too, find #(a,b) but frankly, there aren't many lead-char solutions which aren't ugly, easy to type, and not used by identifiers (or as operators) already. What have we got to chose from? I think `@#%^&* -- none of these are measurably better than # and some are worse. Maybe you could make the point that & looks like a melted lambda. But I see no point in bike shedding over this.
Erik and I worked through most of these options, considering their placement on US and non-US keyboard layouts and their relative "does it look like a function?"-ness. "#" won, not because either of us loved it, but because it was the least bad.
2011/3/26 Wes Garland <wes at page.ca>:
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.
I'd be happy to participate too.
If the goal is to, as Kevin suggested, provide an early vetting service of ideas as to how the language should be by people who know have a detailed knowledge of how the language is, would a ticket system be more appropriate/additionally useful? A ticket system might use scarce attention better since it is 1:1, not 1:n.
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.
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.
khs
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:
This is still a strawman, but <> and [] are both not attractive for multiple reasons as formal parameter brackets, so I see long odds.
On 03/26/2011 07:44 PM, Brendan Eich wrote:
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).
I might be misreading, but I think Wes meant to have as a bracket-y character, such that on seeing it you switch to argument-parsing mode until you hit '{', or something like that, then end the entire thing with another ("bracket-y character"). There's no ambiguity there that I can see, although it has other issues, and wasn't seriously proposed anyway (as I read Wes).
On Mar 26, 2011, at 9:06 PM, Jeff Walden wrote:
On 03/26/2011 07:44 PM, Brendan Eich wrote:
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).
I might be misreading, but I think Wes meant to have
as a bracket-y character, such that on seeing it you switch to argument-parsing mode until you hit '{', or something like that, then end the entire thing with another("bracket-y character"). There's no ambiguity there that I can see, although it has other issues, and wasn't seriously proposed anyway (as I read Wes).
Oh, I took the `` as meta, not concrete. If concrete, they are already used for quasis:
Any quote character delimiting suggest strings, not functions. JS doesn't have to look like other languages in every corner of its syntax, but it does look like some big ones in most respects already, and it's hard to argue for looking like nothing ever seen before, here!
On Sat, Mar 26, 2011 at 10:44 PM, Brendan Eich <brendan at mozilla.com> wrote:
This es-discuss group sounds exactly like that "ES Tech" group -- why make a new one?
I've always considered this group to be about super-fine nit-picky points of ES, clarifications about recent changes, and well-thought out standards proposals. My thought in proposing "ES Tech" was that there is probably room for something with a slightly more casual tone, where ideas could be bounced off people as part of the formation process, and less advanced questions could be asked and answered. But not full of spam.
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.
True that. Turning back my own mental clock, I remember getting flamed once for posting untested code in ... comp.unix.programmer? The flamer was right, and I didn't do it again, but I kept participating.
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.
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).
Not that this was a serious proposal -- but am I missing something, or did you miss the trailing back-tick in my example? Specifically, I don't think this is ambiguous:
FunctionExpression :
function Identifieropt ( FormalParameterListopt ) { FunctionBody }
or
Identifieropt FormalParameterListopt { FunctionBody }
..although my "native thought pattern" is definitely LALR(1). I find LL(k) ambiguities hard to spot, not having worked with a top-down parser-generator since I was in school! Argh, now I'm not sure if that grammar is unambiguous for small k due to nested FunctionExpressions. I don't think there is a comma-expression hazard there, though.
2011/3/27 Wes Garland <wes at page.ca>:
On Sat, Mar 26, 2011 at 10:44 PM, Brendan Eich <brendan at mozilla.com> wrote: FunctionExpression : function Identifieropt ( FormalParameterListopt ) { FunctionBody } or
Identifieropt FormalParameterListopt { FunctionBody }..although my "native thought pattern" is definitely LALR(1). I find LL(k) ambiguities hard to spot, not having worked with a top-down parser-generator since I was in school! Argh, now I'm not sure if that grammar is unambiguous for small k due to nested FunctionExpressions. I don't think there is a comma-expression hazard there, though.
The need to balance the curly brackets in the body makes it unambiguous for nested function expressions. You don't need to look ahead to tell whether a back-tick is an opening or closing back-tick, just remember whether the last-non-comment-non-whitespace token was a close curly that closed a function expression's body. It is ambiguous with strawman:quasis#syntax_normative if quasi type tags are optional.
As covered with Jeff Walden, I misread your `` usage as meta not concrete. And those quote characters are wanted for quasis, and anyway not function-y in any language I know of. Mike Samuel's latest shows they aren't strictly necessary.
Rather than sketch what might look pretty or easy to type and see if it can be made to parse, we could do better by considering nearby languages. In the gist.github.com/888867#comments I ask whether we skirt the bottom-up parsing cliff one more time, and consider
-> {/* no formals */}
() -> {/* no formals /} a -> {/ one formal /} (a,b) -> {/ two formals */}
([d,e],f) -> {/* two formals, first destructures via array pattern */}
These are not all necessary. CoffeeScript supports the first, C# the third, IIRC. The body could be an expression in parentheses (if not of high precedence). Details TBD. But this would get away from the "pick a funny prefix punctuator or symbol" game.
The parsing may be something we can finesse in a top-down parser, by parsing the covering RHS equivalent and then walking the AST to validate that it is a well-formed parameter list.
In no case is anything like quoting required, or IMHO a good idea.
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).
I'm not a parsing expert, but isn't destructuring just as hard to parse top-down as => for functions would be? Given:
{ a: b, c: d } =
A top-down parser will go up to "=" thinking its parsing an object literal. Then it hits the "=" and have to either backtrack, or just transform the object literal AST into a destructuring pattern. Then it can proceed on its merry way.
Wouldn't => work the same way?
(a, b) =>
It parses "(a, b)" thinking it's a grouped comma operator (not exactly a common expression FWIW), then it hits "=>" realizes it's a function
parameter decl, and then either backtracks or just transforms the left-hand AST into a param decl.
I understand this list isn't "teach me the details of the JS grammar", but it isn't obvious to me why an infix function syntax is any harder than destructuring as far as parsing performance is concerned. Empirically, I'd expect it to be less of an issue because the comma operator is so rare and parameter declarations tend to be short. Is it because there are things that would be valid in a parameter declaration that are not valid expressions?
2011/3/29 Bob Nystrom <rnystrom at google.com>:
Wouldn't => work the same way? (a, b) => It parses "(a, b)" thinking it's a grouped comma operator (not exactly a common expression FWIW), then it hits "=>" realizes it's a function parameter decl, and then either backtracks or just transforms the left-hand AST into a param decl.
An AST won't cut it. You have to use a parse tree because there are valid grouped comma operators containing only identifier operands that are not valid parameter lists, e.g. ((a), b)
Once you do have a way to make the necessary distinctions, => is just
another right associative operator that you need to pick a precedence for.
2011/3/29 Mike Samuel <mikesamuel at gmail.com>:
2011/3/29 Bob Nystrom <rnystrom at google.com>:
Wouldn't => work the same way? (a, b) => It parses "(a, b)" thinking it's a grouped comma operator (not exactly a common expression FWIW), then it hits "=>" realizes it's a function parameter decl, and then either backtracks or just transforms the left-hand AST into a param decl.
An AST won't cut it. You have to use a parse tree because there are valid grouped comma operators containing only identifier operands that are not valid parameter lists, e.g. ((a), b)
Once you do have a way to make the necessary distinctions, => is just another right associative operator that you need to pick a precedence for.
The fact that there are parameter lists that are not valid grouped comma operators, () and (a), shouldn't cause problems.
And there shouldn't be any subtle semicolon insertion bugs.
bar = foo () =>
4
will reliably produce a syntax error when the parameter list is stolen by a callable expression on a previous line.
On Mar 29, 2011, at 3:30 PM, Bob Nystrom wrote:
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).
I'm not a parsing expert, but isn't destructuring just as hard to parse top-down as => for functions would be? Given:
{ a: b, c: d } =A top-down parser will go up to "=" thinking its parsing an object literal. Then it hits the "=" and have to either backtrack, or just transform the object literal AST into a destructuring pattern.
That's exactly what we do in SpiderMonkey, and IIRC Rhino does the same.
My point was about parsing, not parsing + some retrospective procedure on the AST that rewrites it. That latter is not just "parsing", it's a separate pass and not formalized in the ECMA-262 specs currently. More below.
Wouldn't => work the same way?
(a, b) =>It parses "(a, b)" thinking it's a grouped comma operator (not exactly a common expression FWIW), then it hits "=>" realizes it's a function parameter decl, and then either backtracks or just transforms the left-hand AST into a param decl.
It ups the ante beyond "pure parsing", but yes, in the same way as destructuring.
One example of the cost of this ante: Harmony wants early error for assignment that would create a global variable, or use of an identifier that is not declared via a lexical binding form. These would have to come in a later pass, or be deferred manually till closing ) without immediately following arrow were parsed.
There is no absolute top-down-parsing-must-be-"easy" requirement, and indeed the formal grammar is LR(1), so we need to validate each edition that way -- via a bottom-up grammar and even automated checker (modulo ASI, which is separable and treated separately).
Waldemar has shown how using only top-down parsing, however formalized, without bottom-up grammatical validation can lead one astray:
Something like the reverse, bottom-up validation without top-down being "easy enough", could also be a problem, since none of the major engines (AFAIK) uses bottom-up parsing.
I understand this list isn't "teach me the details of the JS grammar", but it isn't obvious to me why an infix function syntax is any harder than destructuring as far as parsing performance is concerned.
I agree, and I said so at gist.github.com/888867#comments and here on the list:
which seems to be right before your post in the archive at esdiscuss/2011-March/thread.
So yes, we can certainly consider infix-arrow, but it's more work for top-down parser implementors than leading octothorp or equivalent prefix. Destructuring requires similar but less work. That may not be enough to justify infix-arrow.
As usual, the big question for the future of the standard language is: do TC39 members -- in particular the parser implementors at Apple, Google, Microsoft, Mozilla, and Opera -- all agree?
We have already approved destructuring for ES.next -- it's in the harmony:proposals part of the wiki. But it's not the same in degree of work, even if same in kind measured roughly.
Empirically, I'd expect it to be less of an issue because the comma operator is so rare and parameter declarations tend to be short. Is it because there are things that would be valid in a parameter declaration that are not valid expressions?
Possibly, although if we use | to separate the optional formal receiver parameter declaration from the positional parameters, then we're still ok: (t = u | a, b, c) is a wacky expression: ((t = (u | a)), a, b, c) -- comma with assignment of bitwise-or as first comma-linked operand.
Again the detailed cost analysis shows pain due to precedence shifting. Rewriting this AST in a top-down parser to have a shape more like ((t = u), a, b, c) or, ot label nodes functionally and with quoting elided, formals(opt_this_formal(t, u), a, b, c), might engender some strong complaints from implementors!
As a simple matter of taste, I find the # symbol to be quite ugly and have been thinking of alternatives for shortening function expression syntax.
In working with my own wonky version of promises, I continue to make the same typing error over and over again. This is something like what I mean to type:
obj.doSomething().then(function(val, err) { ... });
But I find myself typing this instead:
obj.doSomething().then(val, err) { ... });
The problem isn't so much the extra typing of the "function" keyword, but the profusion of parens. I'd like to suggest the following form instead.
obj.doSomething().then(<val, err> { ... });
Correct me if I'm wrong, but since expressions cannot start with "<", this shouldn't present any problems for a top-down parser. Is that right?
Thanks, khs
As a simple matter of taste, I find the # symbol to be quite ugly and have been thinking of alternatives for shortening function expression syntax. In working with my own wonky version of promises, I continue to make the same typing error over and over again. This is something like what I mean to type: obj.doSomething().then(function(val, err) { ... }); But I find myself typing this instead: obj.doSomething().then(val, err) { ... }); The problem isn't so much the extra typing of the "function" keyword, but the profusion of parens. I'd like to suggest the following form instead. obj.doSomething().then(<val, err> { ... }); Correct me if I'm wrong, but since expressions cannot start with "<", this shouldn't present any problems for a top-down parser. Is that right? Thanks, khs -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110325/cb09cc67/attachment.html>