On Fri, Jan 13, 2012 at 12:20 AM, Brendan Eich <bren...@mozilla.org> wrote: > We have three coarse-grained alternatives:
If you are going to enumerate all potential alternatives (including ones that you need to be rejected for one reason or another), then a CoffeeScript inspired syntax should be included: (params) -> {body} - Sam Ruby > 1. λ (params) { body } > > 1a. One problem is what should we use for λ? 'lambda', 'block', etc. are not > reserved the syntax. Whatever the identifier (including Greek lambda: λ), > this is an incompatible change. > > 1b. Another problem: this form looks like a function expression with a > different introductory keyword, but Tennent's Correspondence Principle makes > the meaning of body elements including |this| and return/break/continue > radically different. Different-enough semantics should have different > syntax. > > 2. { (params) body } > > Putting the parameter list in parentheses is more consistent with function > syntax, while putting the parameters on the inside stresses the block-ness > over function-ness. By block-ness I mean (ignoring let, const, and function > in Harmony) how code and {code} are equivalent. > > Of course this cuts against the syntax too: block statements are not > first-class callables whose code bodies are evaluated only if invoked, they > are statements evaluated eagerly when reached. This syntax is arguably too > block-like. > > A point that I remember having come up in past TC39 meetings: if we ever > want structuring forms (object literals or destructuring patterns) that use > () for grouping property names, this syntax is future hostile. > > 3. { |params| body } > > This is new-to-JS, idiomatic block-like -- but not too block-statement-like > -- syntax for novel body semantics. > > The bars will drive some people to distraction. Others will grok, or already > do via Ruby. This is not to favor Ruby, just to build on the belief that > some precedent in language design is better than none. > > We could reject (3) in favor of (2) if we had an overriding non-aesthetic > reason. I don't see one. > > Aesthetics vary. The more conventional look of (2) seems like a usability > hazard to me, which trumps aesthetics. Again I'd rather have something more > different-looking to signal the novel application of TCP. > > /be > > > _______________________________________________ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss