Basic Lambdas and Explicit Tail Calls Repackaged

Michael Day mikeday at
Sun Dec 7 15:50:17 PST 2008

Hi Eugene,

> Is your lambda proposal competing with 
> (gave me by 
> Brendon)?

It is a different proposal, I think it helps to have more than one 
proposal, in order to clearly see the different trade offs involved.

> Why would anybody want to use a lambda instead of a function? 2 
> characters less to type? What is the compelling reason, the super idea 
> behind the lambda besides confusing programmers, and more things to 
> implement by compiler writers?

Well, that's a really good question, as lambdas don't sound sufficiently 
different to regular functions in this proposal to be worth doing.

The lambda proposal on the wiki gives the following "Why" reasons:

"A simpler primitive underlying the language’s first-class functions."

Removing 'this' and 'arguments' also gives a simpler primitive, but is 
it enough to bother with?

"Supports defining other features via desugaring without breaking 
equivalence with implicit features (arguments, this, return) — this is 
sometimes described as Tennent’s Correspondence Principle [ 1, 2 ]."

Not clear what this means, or what benefit it brings to either 
JavaScript programmers or implementors.

"A well-tested feature of programming languages since time immemorial."

JavaScript already has higher-order functions, and much fewer languages 
have lambdas where a return returns from the enclosing function.

"Supports tail calls more naturally than function."

I don't see what's unnatural about explicit tail calls in functions.

"Simple, composable features like lambda are useful for other language 
features defined via desugaring/compiling other languages to ES/macros"

What do lambdas in the wiki have that lambdas-as-functions-without-this 
do not have? They seem to have more complexity, but I can't see how they 
are significantly more useful.

Best regards,


Print XML with Prince!

More information about the Es-discuss mailing list