What about:
.(a,b,c) {}
or
..(a,b,c) {}
or
...(a,b,c) {}
Regards,
Eric Suen
----- Original Message -----
From: "Allen Wirfs-Brock"
<[EMAIL PROTECTED]>
Newsgroups: gmane.comp.lang.javascript.ecmascript4.general
To: "Maciej Stachowiak" <[EMAIL PROTECTED]>; "Brendan
Eich" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
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: [EMAIL PROTECTED]
>>[mailto:es-discuss-
>>[EMAIL PROTECTED] On Behalf Of Maciej
>>Stachowiak
>>Sent: Monday, December 01, 2008 12:59 PM
>>To: Brendan Eich
>>Cc: [EMAIL PROTECTED]
>>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
>>[EMAIL PROTECTED]
>>https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
Es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
