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.
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.
Regards,
Maciej
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
