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
