March 28 meeting notes

Brendan Eich brendan at mozilla.org
Thu Mar 29 07:11:52 PDT 2012


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


More information about the es-discuss mailing list