Allen's lambda syntax proposal

Maciej Stachowiak mjs at apple.com
Tue Dec 2 08:48:15 PST 2008


On Dec 2, 2008, at 5:03 AM, Eric Suen wrote:

> What about:
>
> .(a,b,c) {}
>
> or
>
> ..(a,b,c) {}
>
> or
>
> ...(a,b,c) {}

As long as we're giving the bikeshed a few more coats of paint,  
Objective-C is adding block-like closures with ^ as the prefix, so we  
could take inspiration from that:

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

I'm not sure if this would introduce ambiguities in the grammar since  
"^" is already an operator; I tend to think not, because "+" and "-"  
manage to be both unary and binary operators without ambiguity. "^"  
also has a slight resemblance to the greek lambda, which is the reason  
Haskell uses "\". This could support named lambdas without risk of  
clashing with the \u escape.

Regards,
Maciej

>
>
> Regards,
>
> Eric Suen
>
> ----- Original Message -----
> From: "Allen Wirfs-Brock"
> <Allen.Wirfs-Brock-0li6OtcxBFHby3iVrkZq2A at public.gmane.org>
> Newsgroups: gmane.comp.lang.javascript.ecmascript4.general
> To: "Maciej Stachowiak"  
> <mjs-2kanFRK1NckAvxtiuMwx3w at public.gmane.org>; "Brendan
> Eich" <brendan-4eJtQOnFJqFBDgjK7y7TUQ at public.gmane.org>
> Cc: <es-discuss-4eJtQOnFJqFAfugRpC6u6w at public.gmane.org>
> 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 public.gmane.org
>>> [mailto:es-discuss-
>>> bounces-4eJtQOnFJqFAfugRpC6u6w at public.gmane.org] On Behalf Of Maciej
>>> Stachowiak
>>> Sent: Monday, December 01, 2008 12:59 PM
>>> To: Brendan Eich
>>> Cc: es-discuss-4eJtQOnFJqFAfugRpC6u6w at public.gmane.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-4eJtQOnFJqFAfugRpC6u6w at public.gmane.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>
>
> _______________________________________________
> Es-discuss mailing list
> Es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss



More information about the Es-discuss mailing list