On May 1, 2010, at 1:47 PM, Maciej Stachowiak wrote:
On Apr 29, 2010, at 9:09 PM, Brendan Eich wrote:
On Apr 29, 2010, at 7:26 PM, Mark S. Miller wrote:
We can't keep going around on this. I'm all in favor of shorthand
for function, but TC39 virtually dropped lambda. Do we really
need to revive it (and return to label, and probably other things
we probably can't afford)?
What's the metric of "afford" here? If these things impose a
surprising implementation cost, then I'm all ears. Do they?
Maciej's cited objection was not about implementation costs. It was
about what users will expect. If lambda is seen as a shorthand for
function, then return in lambda will be read as return *from* lambda.
There's also the surprising runtime error you get when you return
from a lambda that has escaped and outlived the activation of the
nearest enclosing function.
Implementation complexity goes up too, but the user confusion issue
is primary.
I like the idea of a shorter syntax for functions. However, I don't
think ES4 lambda's goal of referential transparency results in a
useful construct. A syntax for creating a function where "return"
exits the containing function breaks the programmer's concept of a
function, even if it may have some useful formal properties.
Agreed, and this seemed consensus almost 1.5 years ago, on the list
and among TC39 members who spoke up.
In any case, lambda aside, I do think we need at least break and
continue to unshadowed labels in lexically enclosing functions.
This has the same dynamic error problem in case of inner function
escape.
I've *never* heard any request break or continue to a label in an
outer function, btw.
break, continue or return being affected by the containing function
(and whether it is currently on the call stack) just isn't a good
fit for a language with first-class functions. Closures should
capture the lexical environment, not the call stack. Control flow
constructs based on the call stack are really just syntactic sugar
for exceptions, and we already have try-catch.
Agreed, again.
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
