Allen's lambda syntax proposal

Maciej Stachowiak mjs at
Mon Dec 1 17:39:35 PST 2008

On Dec 1, 2008, at 2:32 PM, Allen Wirfs-Brock wrote:

> {|a,b,c| ...} or
> \(a,b,c) {...} or
> {\(a,b,c) ...}
> I could be happy with any of them and can find pros and cons with  
> each.  I think the high order bit should be that a concise closure  
> syntax is possible and desirable. If we agree on that then we just  
> need to pick one.
> The use of \ slightly bothers me because it is takes a character  
> that now is exclusively used in the lexical (token) grammar  
> ( Unicode escapes, string escapes, line continuations)  and gives it  
> syntactic significance. This is probably not a fatal flaw but it  
> would mean that the lexical uses of \ become less visually  
> distinctive.
> Whether someone prefers the parameters inside or outside the braces  
> may be another symptom of whether they are focusing on control  
> abstraction or functional abstraction. With control abstraction you  
> use closures as "blocks" of code that form pieces of the abstraction  
> so it may seems natural from that perspective for the braces to  
> surround the entire "block". This is closer to the syntactic feel of  
> the built-in control statements.  If you are building functional  
> abstractions then you are probably thinking about the closures as  
> functions so placing the formals before the body seems natural.

Can you give an example? Since ECMAScript's built-in control  
structures already have special syntax, it's hard to make anything  
look *exactly* like them.

Here's my best shot at an example. Let's pretend you have a  
withOpenFile function that opens a file, does some work using the  
resulting file handle (assuming there were such things in some host  
extension), and guarantees the file handle will be closed whether on  
normal exit or exception, but passing exceptions through. How would a  
site of use look?

withOpenFile(fileName, { |handle|

withOpenFile(fileName, \(handle) {

Both look a little odd but I'd say the latter resembles built-in  
constructs like a tiny bit more.

> It's fairly common with control abstractions to use 0 argument  
> closures so the readability of {||...}, \(){...}, and {\()...} are  
> probably also worth considering.  Ideally a 0 argument closure would  
> be written as {...} but resolution of the syntactic ambiguities  
> between object literal and such closures (particularly in the  
> presence of statement labels) seems too difficult to contend with.

Perhaps with the backslash idea, a 0-argument lambda could have a  
short form of just \ {...}. I'm trying to think of a useful control  
construct that takes thunks. Maybe implementing memoized lazy lists, a  
la scheme, so you can do stuff like:

lazyPair(val1, \ { computeRestOfList(); } );

var fibonacciNumbers = \ {
     let fib = \(a, b) { lazyPair(b, \ { fib(b, a + b) }) };
     lazyPair(0, fib(0, 1));

(I'm skipping the definition of lazyPair and the lazyCar / lazyCdr  
you'd need to walk the stream).

Seems adequately readable.

For comparison:

lazyPair(val1, { || computeRestOfList(); } );

var fibonacciNumbers = { ||
     let fib = { |a, b| lazyPair(b, { || fib(b, a + b) }) };
     lazyPair(0, fib(0, 1));

Maybe it's just lack of familiarity but the second version seems less  
readable and natural to me.

> My focus on supporting control abstraction may be mute.  While  
> Smalltalk and Ruby show that power of such abstraction mechanisms it  
> takes more than just a concise block-like closure notation to  
> achieve it. The complexity of the BGGA Java closure proposal (and  
> the associated controversy) shows how hard it can be to fully  
> support control abstraction using C syntax (and, of course, Java  
> semantics).

I think it's possible to build useful control abstractions with a  
concise block-like syntax. But an important factor here is making  
these look natural in the context of the language as well as concise.  
Ruby and Smalltalk have overall designs that make them friendly to a  
smalltalkish block syntax, so your custom control constructs look just  
like the built-in ones (or conversely you could claim none are built  
in). In ECMAScript you can't have them look exactly the same, but I  
think the Haskellish backslash style fits in a little better.


> Allen
>> -----Original Message-----
>> From: es-discuss-bounces at [mailto:es-discuss-
>> bounces at] On Behalf Of Maciej Stachowiak
>> Sent: Monday, December 01, 2008 12:59 PM
>> To: Brendan Eich
>> Cc: es-discuss at
>> Subject: Re: Allen's lambda syntax proposal
>> On Nov 29, 2008, at 10:30 PM, Brendan Eich wrote:
>>> At the TC39 meeting two weeks ago in Kona, we had a brief
>>> bikeshedding discussion about lambda syntax and why it matters.
>>> Observation: blocks in Smalltalk being lightweight means users don't
>>> mind writing them for control abstractions, compared to JS functions
>>> in ES3. In Smalltalk, ignoring JS, it's hard to beat [ and ] as
>>> overhead, although one must count the message selector and its
>>> punctuation too.
>>> Allen Wirfs-Brock put his proposal, which will not shock you who
>>> know Smalltalk or Allen, on the whiteboard:
>>> // Instead of lambda (a, b, c) { ... }, why not:
>>> { |a, b, c| ... } ?
>> I like the brevity, but having the formals inside the block and in ||
>> delimiters seems like it will look weird in an ECMAScript program.  
>> For
>> function declarations the parameters go in parentheses, and for calls
>> (presumably also for lambda calls), the arguments go in parens. If
>> brevity is important, why not lift the lambda syntax from modern pure
>> functional languages:
>> \(a, b, c) { ... }
>> That's backslash as a lambda operator. This has one more character
>> than your version, but will make formals and parameters look the same
>> for functions, lambdas, and calls, and will avoid putting the formals
>> inside the body which I think is confusing and visually hard to scan.
>> Regards,
>> Maciej
>> _______________________________________________
>> Es-discuss mailing list
>> Es-discuss at

More information about the Es-discuss mailing list