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}'?
Parameters have optional guards (in the future), default value
initialisers, destructuring patterns and so on. Using : is no good
because, while we might manage to keep the grammar unambiguous, it is
too visually light and is not a close-bracket. It's already used in ?:
and labels.
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).
Consider { x, y=a?b:c : body }.
/be
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
|
