Allen's lambda syntax proposal
Jeff Watkins
watkins at apple.com
Tue Dec 2 10:13:56 PST 2008
On 1 Dec, 2008, at 10:18 PM, Peter Michaux wrote:
> One problem is if the argument list needs to take two lambdas, then
> where would the second lambda go? One inside the arguments list and
> one after? Why is one lambda more important or deserving of a special
> place compared with the other lambda?
I've been writing JS a long time and I don't frequently find myself
wanting to pass more than one function/lambda to another function. On
the (very) rare occasion when I do, I suspect I'm not calling a
control-structure-like function. Then I'd be comfortable passing two
lambdas as arguments.
Since the goal seems to be allowing control structures like Smalltalk
(yay!), how about specifying that one lambda that follows a function
invocation is passed as the final argument to the invocation. You can
write the invocation:
withNode(node, {|n| ... })
and I'll write it as:
withNode(node)
{ |n|
...
}
> Some API designers won't like the trailing lambda syntax and some
> will. Then we end up with inconsistent APIs.
I think if lambdas can be specified outside the parameter list, API
designers will feel pressure from those who use their APIs to adopt
the trailing lambda style. This would only be a significant issue when
the API is expecting a single lambda.
And regarding using the full term lambda in the syntax, I think I'm
not alone that I'd have a hard time adopting lambdas over functions
without a significant improvement in syntax -- and changing the name
from function to lambda isn't significant. Especially considering that
the initial implementations of lambdas might not hold a significant
performance improvement over functions.
Of course, it would also be super cool if I could write something like:
{ |n|
hide: function()
{
n.style.display='none';
},
show: function()
{
n.style.display='';
},
etc...
}
Of course if I didn't have to pay the cost of instantiating a new
function for every object instance, that would make something like
this worthwhile.
Jeff
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20081202/2d7a06a8/attachment.html>
More information about the Es-discuss
mailing list