March 28 meeting notes
rossberg at google.com
Thu Mar 29 08:10:33 PDT 2012
On 29 March 2012 16:11, Brendan Eich <brendan at mozilla.org> wrote:
> 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.
For me, the biggest blow against TCP lambda forms in general was Mark's
observation regarding the incompatibility with 'yield' that you mention in
the other post. If the TCP does not cover the whole language, then that
vastly reduces lambda's utility as a general abstraction mechanism for
compiler or macro writers. It means that you cannot generally replace a
'for' loop with a 'forEach' method in a generator. That makes it look like
a rather dead born idea.
(Of course, you can turn that around as an argument against generators in
their current form, because it just demonstrates that they are not properly
compositional. But short of adopting more general continuation support,
which nobody wants, there doesn't seem to be much of an alternative.)
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.
I actually think this is a less severe problem. Ignoring the issue of
potential confusion for users (which is real), the main thing lacking there
in terms of expressiveness is some labelled variant of 'return', analogous
to break and continue. If we were so inclined, I'm sure we could come up
with something usable on that front.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss