Allen's lambda syntax proposal

[Eric Suen]

'~' is ambiguities usless you using two NO_LINE_BREAK like:

'~' NO_LINE_BREAK (...) NO_LINE_BREAK {...}

'.' may not looks good, but it does not introduce new token
like '\' or 'lambda'

Regards,

Eric Suen

----- Original Message ----- 
From: "Maciej Stachowiak" <mjs-2kanFRK1NckAvxtiuMwx3w at public.gmane.org>
Newsgroups: gmane.comp.lang.javascript.ecmascript4.general
To: "Eric Suen" <eric.suen.tech-Re5JQEeQqe8AvxtiuMwx3w at public.gmane.org>
Cc: "Brendan Eich" <brendan-4eJtQOnFJqFBDgjK7y7TUQ at public.gmane.org>; 
"es-discuss" <es-discuss-4eJtQOnFJqFAfugRpC6u6w at public.gmane.org>
Sent: Wednesday, December 03, 2008 12:48 AM
Subject: Re: Allen's lambda syntax proposal


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