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"
<[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
_______________________________________________
Es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
