Allen's lambda syntax proposal
Brendan Eich
brendan at mozilla.com
Fri Dec 5 15:11:02 PST 2008
On Dec 5, 2008, at 2:57 PM, Michael Day wrote:
>> This is all speculation, but here's my non-speculative claim:
>> lambda syntax should not look so much like function syntax if
>> return within the body behaves completely differently. We would
>> want syntax very different from function (i.e., not lambda (args)
>> {body} -- sorry, Peter Michaux). Or else we should revisit the
>> wisdom of applying TCP to lambdas.
>
> I'm unconvinced that TCP needs to apply to statements; it seems like
> a more valuable property when applied to expressions, even though
> JavaScript is not referentially transparent to begin with.
Good points.
> Anyway, these three options look good to me:
>
> (1) Expression lambdas: lambdas whose body is an expression.
>
> var x = lambda(y, z) y + z
Would need parens around the body, if this is a primary expression,
else reduce-reduce conflict.
> Solves the problem with completion leakage, solves the nested return/
> break/continue issue. However, quite limited in usage, and makes it
> difficult to use lambdas to replace functions as they can't contain
> loop statements. (Hello, recursion! :)
We could mandate tail recursive call sites in the spec so people could
count on it cross-browser.
http://bugs.ecmascript.org/ticket/215
http://bugs.ecmascript.org/ticket/215 (not be necessary for expression-
enclosed tail calls)
> (2) Function lambdas: objects just like functions, except no "this"
> or "arguments", and perhaps some guarantees about tail calls?
>
> var x = lambda(y, z) { return y + z }
>
> This seems the easiest for programmers to understand, and avoids the
> return/break issues. It violates TCP for statements, but I don't
> think that really matters in practice; after all, so do functions.
I must agree, since this looks like function syntax, with a new
introductory keyword. TCP must yield.
> (3) Parametric blocks: where a block, possibly taking arguments, can
> be passed around as an object. The key use-case for this seems to be
> creating new control abstractions. I would argue that blocks should
> not be usable as expressions, and the completion value cannot be
> captured (unless using eval) for consistency with existing statement
> behaviour.
>
> var a = block { ... statements ... }
> var b = block(x, y) { ... statements using x and y ... }
>
> call b(1, 2); // this is a statement, not an expression
>
> Unfortunately, object literals also look like blocks, and there is
> no perfect syntax for this that fits neatly into the existing
> language. without using bulky keywords. While this option preserves
> TCP, I don't think JavaScript really needs this feature, and the
> power/complexity ratio doesn't measure up.
Agreed. Past efforts to add just this kind of block have failed to get
anywhere.
>> I agree if lambda looks like function or is sold as a "better
>> function". If it looks more like a block, or something else, that
>> might mitigate the return hazard. Michael Day wondered if we
>> confined the body to an expression language -- that would eliminate
>> the return hazard.
>
> I like options (1) and (2) above. The current proposal on the wiki
> feels like all three options mashed together, and I find it
> difficult make sense of it as a basic construct.
Including Dave to get his thoughts, in case he is reading es-discuss
in a digest or deferred fashion.
/be
More information about the Es-discuss
mailing list