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.
> 
> Please read
> 
> 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


More information about the Es-discuss mailing list