Domenic Denicola wrote:
Minor question: There are no examples of "very empty" arrow functions, e.g. `=>`
or `=> 5`. And from what I can tell reading the grammar , they are not allowed.
They were allowed in the grammar I wrote -- see the wiki history.
Several TC39ers reacted badly to them yesterday and rather than wreck
consensus over them, I took 'em out. Perhaps we could add them back with
more time.
Bigger question: It sounds like TCP was sacrificed in favor of maximal minimalism,
which makes sense. But, is this strawman friendly toward future TCP endeavors,
perhaps in ES.next.next? For example, if `do` expressions were specced in the way
discussed previously, could putting one to the right of the => result in TCP
semantics?
There was a lengthy discussion of what "TCP" means. JS has statements as
well as expressions, it's the C curse by way of "make it look like
Java". So adding a TCP lambda form now, however good for macros,
compiler writers, and certain users of the language, is likely to create
confusion.
The biggest worry has been the "completion value leak". This is why I've
argued block-lambdas are better for a pure TCP form than anything built
on function's body plan or "clade". Yesterday,
Luke made a stronger point: TCP 'return' means async callbacks (e.g.
promise when functions) must be written ML-style, with return value in
tail position. Callbacks can be lengthy, so writing and if-else nest
with a variable holding the r.v. to achieve this is awkward and users
will prefer early returns (so the calllback's spine is the normal
execution path). But TCP will make these wrong-return bugs.
In general I sensed a new consensus: it's too late to wedge TCP into JS,
at least under any "___ function syntax". Allen held out hope for
block-lambdas later but others (Mark and I at least) view them as
effectively ruled out by arrows.
Dave wrote the equivalence he wants for "TCP" (an overloaded TLA, we've
talked past one another by abusing it):
e ~= do { e; }
where e is an expression and not a statement. So lexical |this| is still
important (lack of it is an ongoing source of bugs). And we ban
'arguments' in arrow bodies.
We may add a pure TCP form such as block-lambdas later, but with arrows
"in", I give future lambda-ish additions very long odds. Don't want two
things.
The deeper conclusion is that the C curse in JS, and millions of users
learning JS-as-it-is over 15 years, in particular using early return,
weigh heavily against a late TCP lambda form. Certainly against one in
function's clade.
/be
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
