three small proposals: the bikeshed cometh!

Maciej Stachowiak mjs at apple.com
Sat May 1 13:47:31 PDT 2010


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



More information about the es-discuss mailing list