Allen's lambda syntax proposal
Eric Suen
eric.suen.tech at gmail.com
Tue Dec 2 09:49:29 PST 2008
'~' 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
More information about the Es-discuss
mailing list