Allen's lambda syntax proposal

Eric Suen at
Tue Dec 2 05:03:18 PST 2008

What about:

.(a,b,c) {}


..(a,b,c) {}


...(a,b,c) {}


Eric Suen

----- Original Message ----- 
From: "Allen Wirfs-Brock" 
<Allen.Wirfs-Brock-0li6OtcxBFHby3iVrkZq2A at>
Newsgroups: gmane.comp.lang.javascript.ecmascript4.general
To: "Maciej Stachowiak" <mjs-2kanFRK1NckAvxtiuMwx3w at>; "Brendan 
Eich" <brendan-4eJtQOnFJqFBDgjK7y7TUQ at>
Cc: <es-discuss-4eJtQOnFJqFAfugRpC6u6w at>
Sent: Tuesday, December 02, 2008 6:32 AM
Subject: RE: Allen's lambda syntax proposal

> {|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.
> 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.
> 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).
> Allen
>>-----Original Message-----
>>From: es-discuss-bounces-4eJtQOnFJqFAfugRpC6u6w at 
>>bounces-4eJtQOnFJqFAfugRpC6u6w at] On Behalf Of Maciej 
>>Sent: Monday, December 01, 2008 12:59 PM
>>To: Brendan Eich
>>Cc: es-discuss-4eJtQOnFJqFAfugRpC6u6w 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.
>>Es-discuss mailing list
>>Es-discuss-4eJtQOnFJqFAfugRpC6u6w at

More information about the Es-discuss mailing list