# Allen's lambda syntax proposal

Eugene Lazutkin eugene.lazutkin at gmail.com
Fri Dec 5 13:45:47 PST 2008

```Thank you for useful links and explanations. Correct me if I am wrong
but in the current form lambda is a facility that duplicates a function.
More than that it reminds my old languages that had separate keywords
for functions (our "lambda"?) and procedures (our "function"?).

Writing code I frequently need small functions (or lambdas). The smaller
the code the better --- it allows to be concise and does not obscure the
intent. That's why I prefer to use lambda's proposed by Oliver Steele
(http://osteele.com/sources/javascript/functional/), which have a lot of
problems being a pure JavaScript implementation. Writing a factorial
using a linear recursion combinator with lambdas:

var fact1 = linrec("<= 1", "1", "[n - 1]", "m * n[0]");

is simple and more readable than the equivalent:

var fact2 = linrec(
function(n){ return n <= 1; },
function(){ return 1; },
function(n){ return [n - 1]; },
function(m, n){ return m * n[0]; });

I typed 200% more text, and the readability went down by the same 200%
--- because I added 200% of the technical noise not relevant to the
algorithm itself. Anything that improves on that is good in my book.
Lambdas are good:

var fact3 = linrec(
lambda(n) n <= 1,
lambda() 1,
lambda(n) [n - 1],
lambda(m, n) m * n[0]);

Shortcuts for lambdas are better:

var fact4 = linrec(\(n) n <= 1, \() 1, \(n) [n - 1], \(m, n) m * n[0]);

I perceive them as less noisy.

The link you gave features long lambdas and I don't see what they buy
vs. the regular functions. This is the example from that page:

lambda(i) {
if (!isNumeric(i))
// etc.
else if (i < 0)
// etc.
else if (i < params.length)
params[i][0]()
else {
i -= params.length;
if (i < rest.length)
rest[i]
else
// etc.
}
}

Written as function it is not that long or less clear:

function(i) {
if (!isNumeric(i))
// etc.
else if (i < 0)
// etc.
else if (i < params.length)
return params[i][0]()
else {
i -= params.length;
if (i < rest.length)
return rest[i]
else
// etc.
}
}

My point is we gain more by concentrating on small light-weight snippets
than on one more way to code a big function.

So concentrating on small snippets:

1) Reducing "technicalities" and the boilerplate improves the clarity of
the code.

1a) I don't mind if lambdas don't have their own "this", "arguments", or
a scope --- from my experience they are rarely used in small snippets.

1b) I am all for skipping "return" --- it reduces the boilerplate for
small snippets.

2) Named lambdas, and parameter defaults are of little value. Use
functions if you truly need a named functionality. Otherwise assign it
to a variable and pass around (rarely needed).

3) Losing the keyword "lambda" in favor of a small shortcut (e.g., \)
will be of great value --- less noise, less boilerplate, less typing,
less opportunities to mistype.

I suggest paring down "lambda" by shedding names, default parameters,
and possibly the keyword "lambda" itself --- it reduces complexity, no
chance for ambiguity, easier to implement, easier to use.

Thanks,

Eugene

Brendan Eich wrote:
> On Dec 4, 2008, at 5:44 PM, Eugene Lazutkin wrote:
>
>> If you started to recap the history of this discussion, could you (or
>> anybody else in the know) verbalize following things:
>>
>> 1) What is the difference between the function and the lambda? I am not
>> talking about their syntax, I want to understand the semantic
>> difference, if there is any.
>
>
> http://wiki.ecmascript.org/doku.php?id=strawman:lambdas
>
>
>> 2) Why is it important for a lambda to have an optional name?
>
> It may not be.
>
>
>> What's
>> wrong with using a function, if we want a name? IMHO lambda should have
>> the minimalistic syntax.
>
> "Minimalistic" does not define itself. The question is what is the
> minimal syntax given various constraints.
>
> Church's Lambdas take one argument only. One can curry by hand. Why
> isn't that the minimum minimum?
>
>
>> 3) Why is it important to be able to specify parameter defaults in
>> lambda? Again, it looks like an extra sugar to me that can be covered by
>> a function with parameter defaults.
>
> See
>
> https://mail.mozilla.org/pipermail/es-discuss/2008-October/007715.html
>
> Also consider that default parameters are a convenience we want lambdas
> to have if we believe functions should be avoided for much lambda-coding
> by hand. The countervailing argument is that lambdas have unintended
> completion value hazards, but Schemers and others don't worry about
> these and would prefer not to have to run back to functions and lose
> Tennent's Correspondence Principle every time default parameters beckon.
>
>
>> The reason I ask is a lot of discussion is going around "but if it has a
>> name" and "but if it has a default". If it doesn't have a name I would
>> be satisfied personally with \(a, b) {...} --- it doesn't clash with
>> anything. Or even with \(a, b) expr.
>
>
> You're right to question name to rescue \, but trying to minimize
> lambdas won't save all the proposed syntaxes. We're making progress in
> finding some to be in trouble, if not fatally flawed.
>
> /be
```