Arrows are not a live
proposal because TC39 wants to keep LR(1) parsing for grammar validation
(checking for ambiguities). We do not have consensus to change and
there's no champion working on a credible alternative.
I could have dredged them up but they really are not happening, whereas
we have recurring and live proposals for the three body-plans I listed.
/be
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
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
Sigh. Never mind, I'm
thinking of statement not _expression_ context -- and you can't start an
_expression_ statement with {. Parade's back on. :-)
/be
Sorry, thought about it
more and I'm raining on your (and dherman's) parade :-(.
In an _expression_ but not statement context,
... { (x) e; }
is already a valid JS program if e begins with (, [, +, or - (the last
two intended as unary operators but becoming binary).
Note that | bracketing avoids this problem. In no case can JS of any
extant version have a legal sequence {|.
But because {( is already allowed, what comes after the closing ) can be
the continuation of a parenthesized _expression_.
Even if you don't buy my "better to look different because not function"
argument, this tilts the balance.
/be
... continuing
with my sent-too-soon message:
function() {
asyncAction(..., { (a, b) a.add(b); } }
}
You're right, this could be done. Allen's right that aesthetics matter,
and so (aesthetic sensibilities in various people were formed by these)
do older languages. Ruby uses || not (). Smalltalk uses | but
differently, and of course does not use {}.
Apart from aesthetics, I argue that || are better because they are
different from the overloaded () pair, which mean _expression_ grouping in
the nearby context of the body of the block-lambda, e.g. a.add()b;
above. () also are used around formal parameter lists. And of course
they are used for control structure heads, e.g. if (foo).
Rather than overloading () yet again, for a different formal parameter
list context (block-lambda parameter list after {), which is immediately
adjacent to an _expression_-statement contexts (the block-lambda body), I
believe we should use ||.
The Ruby precedent is another reason, and a particular reason to use |
instead of some other candidate. But I'm mainly trying to persuade you
here that () is not the best choice just because it brackets formal
parameter lists for functions.
/be
|
