I have an obvious bias towards 1 because I think Unicode symbols
describe much better the underlying intentions and semantics than
their ASCII alternatives (usually), however not many people creates
mappings for these symbols on their .XCompose (or even have a compose
key handy).
I remember you mentioning that the Haskell-ish alternative `\x, y {
body }' or `.\x, y { body }' was not practical, because \ is already a
valid escaping character in identifiers (?)
Given those above, despite my usual disliking of Ruby syntax, I prefer
the pipes over parenthesis, given the latter has an already too
overloaded semantics, such that `{ (foo, bar) (2) }' would look pretty
confusing, at least to me. However, what about `{x, y: body}'? Granted
we don't allow labels immediately following a lambda block (and I'm
not sure labels are used much in the language, I could be wrong
however).
2012/1/13 Brendan Eich <bren...@mozilla.org>:
> We have three coarse-grained alternatives:
>
> 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
