Allen's lambda syntax proposal

Allen Wirfs-Brock Allen.Wirfs-Brock at microsoft.com
Mon Dec 1 14:32:11 PST 2008


{|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 at mozilla.org [mailto:es-discuss-
>bounces at mozilla.org] On Behalf Of Maciej Stachowiak
>Sent: Monday, December 01, 2008 12:59 PM
>To: Brendan Eich
>Cc: es-discuss at mozilla.org
>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 mozilla.org
>https://mail.mozilla.org/listinfo/es-discuss



More information about the Es-discuss mailing list