Allen's lambda syntax proposal

[Jeff Watkins]

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>