{|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
