^ also has a slight resemblance to the greek lambda, which is the
reason Haskell uses \.
As an aside, the circumflex is actually the precursor to lambda:
We end this introduction by telling what seems to be the story how
the letter 'λ' was chosen to denote function abstraction. In Principia
On Wed, Dec 17, 2008 at 9:53 PM, Yuh-Ruey Chen maian...@gmail.com wrote:
Lex Spoon wrote:
On this list, the = form has so far been dismissed due to parsing
concerns. If that's the only reason, let me try and allay that worry
and put that horse back in the race. Scala also has a comma
On Dec 17, 2008, at 1:42 PM, Lex Spoon wrote:
I can share some history for the = form. It's disconcerting that
everyone associates it with C#, because they are open about copying
the syntax from Scala.
It's for Ecma solidarity -- we are indirectly boosting another Ecma
standard (C# is
On Mon, Dec 1, 2008 at 3:19 PM, Allen Wirfs-Brock
allen.wirfs-br...@microsoft.com wrote:
Just to clarify some speculation, the syntax I proposed ({||}) was
solely inspired by Smalltalk and tempered by the parsing realities
of a C-like syntax. Any similarities to Ruby constructs are probably
Breton Slivka wrote:
On Sat, Dec 6, 2008 at 9:57 AM, Michael Day [EMAIL PROTECTED] wrote:
(1) Expression lambdas: lambdas whose body is an expression.
var x = lambda(y, z) y + z
Solves the problem with completion leakage, solves the nested
return/break/continue issue. However, quite
Yuh-Ruey Chen wrote:
Breton Slivka wrote:
On Sat, Dec 6, 2008 at 9:57 AM, Michael Day [EMAIL PROTECTED] wrote:
(1) Expression lambdas: lambdas whose body is an expression.
var x = lambda(y, z) y + z
Solves the problem with completion leakage, solves the nested
return/break/continue issue.
Peter Michaux wrote:
On Sat, Dec 6, 2008 at 7:51 PM, David-Sarah Hopwood
[EMAIL PROTECTED] wrote:
The keyword 'function' shouldn't be used for this because a lambda is
not a function. However,
const name(formals) ...
let name(formals) ...
could be sugar for
const name =
David-Sarah Hopwood wrote:
Jon Zeppieri wrote:
On Sat, Dec 6, 2008 at 11:49 AM, Maciej Stachowiak [EMAIL PROTECTED] wrote:
On Dec 5, 2008, at 11:12 PM, Jon Zeppieri wrote:
I don't get it. What issue is raised by return-to-label that isn't
already raised by exceptions? [...]
Also, what was
On 2008-12-06, at 00:23EST, David-Sarah Hopwood wrote:
P T Withington wrote:
Would it work to move the parameter list inside the block (as in the
Smalltalk way, but as a regular parameter list, not using ||'s)?
{(a, b) a + b}
AFAICT, `{(` is a syntax error for an expression in es3.
I
Alex Russell wrote:
Indeed, it can look like an expression to begin a name assignment:
var thinger = {(foo+bar): ... };
Has a syntax like this been shot down yet?:
var thinger = {{ foo, bar }: ... };
Since objects (much less literals) aren't used as keys in hashes
often, this
Alex Russell wrote:
On Dec 5, 2008, at 9:23 PM, David-Sarah Hopwood wrote:
P T Withington wrote:
Would it work to move the parameter list inside the block (as in the
Smalltalk way, but as a regular parameter list, not using ||'s)?
{(a, b) a + b}
AFAICT, `{(` is a syntax error for an
This is ambiguous
{(a, b)
a + b}
is
{(a,b);
a+b
}
unless use no line break restrict and it is difficult to parse
P T Withington wrote:
Would it work to move the parameter list inside the block (as in the
Smalltalk way, but as a regular parameter list, not using ||'s)?
{(a, b) a + b}
On Dec 5, 2008, at 11:12 PM, Jon Zeppieri wrote:
I don't get it. What issue is raised by return-to-label that isn't
already raised by exceptions? They're practically the same thing,
only return-to-label is *easier* to analyze statically, because
'return' can only jump to a label that is
On Sat, Dec 6, 2008 at 11:49 AM, Maciej Stachowiak [EMAIL PROTECTED] wrote:
On Dec 5, 2008, at 11:12 PM, Jon Zeppieri wrote:
I don't get it. What issue is raised by return-to-label that isn't
already raised by exceptions? They're practically the same thing,
only return-to-label is
On Dec 6, 2008, at 9:57 AM, Jon Zeppieri wrote:
On Sat, Dec 6, 2008 at 11:49 AM, Maciej Stachowiak [EMAIL PROTECTED]
wrote:
On Dec 5, 2008, at 11:12 PM, Jon Zeppieri wrote:
I don't get it. What issue is raised by return-to-label that isn't
already raised by exceptions? They're
On Sat, Dec 6, 2008 at 2:03 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote:
On Dec 6, 2008, at 9:57 AM, Jon Zeppieri wrote:
On Sat, Dec 6, 2008 at 11:49 AM, Maciej Stachowiak [EMAIL PROTECTED] wrote:
On Dec 5, 2008, at 11:12 PM, Jon Zeppieri wrote:
I don't get it. What issue is raised by
Eric Suen wrote:
This is ambiguous
{(a, b)
a + b}
is
{(a,b);
a+b
}
This example isn't ambiguous, because an ExpressionStatement cannot start
with '{', therefore this is a block. However the fact that a lambda
starting an ExpressionStatement would have to be parenthesized is a
valid
But in page:
http://wiki.ecmascript.org/doku.php?id=strawman:lambdas
lambda is not just a expression, it could be a Declaration.
If lambda is only a expression, that is why I suggest in post:
https://mail.mozilla.org/pipermail/es-discuss/2008-December/008382.html
This is ambiguous
{(a, b)
Eric Suen wrote:
But in page:
http://wiki.ecmascript.org/doku.php?id=strawman:lambdas
lambda is not just a expression, it could be a Declaration.
If lambda is only a expression, that is why I suggest in post:
https://mail.mozilla.org/pipermail/es-discuss/2008-December/008382.html
#
On Dec 6, 2008, at 9:19 PM, Peter Michaux wrote:
On Sat, Dec 6, 2008 at 7:51 PM, David-Sarah Hopwood
[EMAIL PROTECTED] wrote:
The keyword 'function' shouldn't be used for this because a lambda is
not a function. However,
const name(formals) ...
let name(formals) ...
could be sugar for
Hi Brendan,
This is the other hazard with lambdas. The program equivalences
Tennent's Correspondence Principle enables are good for refactoring,
but bad for thinkos like the above.
It seems like most of the problems come from lambdas being able to
contain statements as well as expressions.
On Dec 4, 2008, at 10:27 PM, Brendan Eich wrote:
On Dec 4, 2008, at 10:12 PM, Brendan Eich wrote:
On Dec 4, 2008, at 7:45 PM, Michael Day wrote:
Hi Brendan,
The main contention about lambdas ignoring syntax is whether the
completion-value creates a hazard that needs to be treated
From: Brendan Eich [mailto:[EMAIL PROTECTED]
The return hazard exists in Smalltalk too. What's different here that
makes you choose differently? Of course, there are more choices than
Tennent-to-the-max lambdas or-else classes-as-sugar.
The difference is in the foundation language we are
Thank you for useful links and explanations. Correct me if I am wrong
but in the current form lambda is a facility that duplicates a function.
More than that it reminds my old languages that had separate keywords
for functions (our lambda?) and procedures (our function?).
Writing code I
On Dec 5, 2008, at 12:49 PM, Allen Wirfs-Brock wrote:
From: Brendan Eich [mailto:[EMAIL PROTECTED]
The return hazard exists in Smalltalk too. What's different here that
makes you choose differently? Of course, there are more choices than
Tennent-to-the-max lambdas or-else classes-as-sugar.
This is all speculation, but here's my non-speculative claim: lambda
syntax should not look so much like function syntax if return within the
body behaves completely differently. We would want syntax very different
from function (i.e., not lambda (args) {body} -- sorry, Peter Michaux).
Or else
Why not using two version, one is for definition like:
Lambda name (a,b,c) {
}
and for expression, you can use both, like:
a = lambda (a,b,c) {
}
and
a = (a,b,c) {
}
Yes, it doesn't contain a lambda expression, just like:
a = x
/x/i
is not same as:
a = x;
/x/i
they both right but
Would it work to move the parameter list inside the block (as in the
Smalltalk way, but as a regular parameter list, not using ||'s)?
{(a, b) a + b}
AFAICT, `{(` is a syntax error for an expression in es3.
___
Es-discuss mailing list
On Dec 3, 2008, at 6:30 PM, Brendan Eich wrote:
On Dec 3, 2008, at 6:18 PM, Maciej Stachowiak wrote:
x = x
+x
That is equivalent to
x = x + x;
so the case with ^ should not differ. (Were you testing in an
interactive REPL?)
I didn't test, I just knew this case must be disambiguated
On Dec 4, 2008, at 7:18 AM, Michael wrote:
Would this form also be ambiguous and/or too difficult to parse?
{= 9*9}()
{a = a+b}(12)
{(a,b) = a+b}(12,6)
I imagine it would be problematic for a top-down parser because you
may have to parse an unbounded number of characters to determine if
On Wed, Dec 3, 2008 at 7:25 PM, Jon Zeppieri [EMAIL PROTECTED] wrote:
Okay -- so we agree. In that case, it's clear that your proposed syntax:
(a,b,c) {...}
has the same problem, right? Any valid ES3 infix operator will have
the same problem, if we use it as a prefix lambda operator.
2008/12/4 Mark S. Miller [EMAIL PROTECTED]:
Welcome to the syntax races. lambda takes an early lead, but drops back
because of too much weight. For a while, it's neck and neck between || and
^, with \ following closely and fn, , and other trailing. Many old
timers (including your commentator)
On Dec 4, 2008, at 10:28 AM, Maciej Stachowiak wrote:
On Dec 4, 2008, at 7:18 AM, Michael wrote:
Would this form also be ambiguous and/or too difficult to parse?
{= 9*9}()
{a = a+b}(12)
{(a,b) = a+b}(12,6)
I imagine it would be problematic for a top-down parser because you
may have to
On 2008-12-04, at 15:23EST, David-Sarah Hopwood wrote:
Arguably, the problem here is that semicolon insertion is and always
was a bad idea.
whinge
That and not requiring whitespace around operators, thus taking away a
huge domain of possible multi-symbol names (such as := for
On Thu, Dec 4, 2008 at 3:23 PM, David-Sarah Hopwood
[EMAIL PROTECTED] wrote:
Jon Zeppieri wrote:
And, if it is on the same line, it's still bad for a top-down parser:
^(x) {
x = x * x
^(a,b,c,d,e,f,g) {x}
}
Same result as above.
Actually, I think we're both wrong. If I'm reading
Mark S. Miller wrote:
[...] \ has taken the lead
There's still #, @, and ` (and of course keywords like lambda and fn).
None of these are as mnemonic as \, but they leave \ as a purely
lexical escape character.
It's quite ironic that we are still limited, as Church was, in
which characters
David-Sarah Hopwood wrote:
Jon Zeppieri wrote:
[...]
The opening brace will need to be on the same line as the formals,
otherwise the syntax is ambiguous:
^(x) {
x = x * x
^(a,b,c,d,e,f,g)
{
x
}
}
Strictly speaking, the syntax is not ambiguous; it just is not parsed
how
On Dec 4, 2008, at 12:52 PM, David-Sarah Hopwood wrote:
Sorry, not the same result. This would be formally a syntax error,
although note that some implementations do perform semicolon insertion
even at non-line-boundaries.
Yes, that bothers me (I'm feeling guilty here: I could use a
On Dec 4, 2008, at 2:31 PM, Breton Slivka wrote:
I admit this seems ludicrous at its face, but admittedly I have not
really seen the arguments against λ as an abbreviated lambda syntax
yet.
Not compatibly: ES3 already allows Unicode identifiers, including
Greek Lambda. Other Mathematical
[oops, sent from the wrong address...]
2008/12/4 Breton Slivka [EMAIL PROTECTED]:
this may be a stupid question, but why? Is it really so impossible to
have λ(a,b,c){} ?
Last time I brought this up, Brendan made fun of me on a podcast. :(
You guys seem to have no trouble typing it. It's
On Fri, Dec 5, 2008 at 9:35 AM, Brendan Eich [EMAIL PROTECTED] wrote:
On Dec 4, 2008, at 2:31 PM, Breton Slivka wrote:
I admit this seems ludicrous at its face, but admittedly I have not
really seen the arguments against λ as an abbreviated lambda syntax
yet.
Not compatibly: ES3 already
] [mailto:[EMAIL PROTECTED]
On Behalf Of Jon Zeppieri
Sent: Thursday, December 04, 2008 4:46 PM
To: es-discuss@mozilla.org
Subject: Re: Allen's lambda syntax proposal
[oops, sent from the wrong address...]
2008/12/4 Breton Slivka [EMAIL PROTECTED]:
this may be a stupid question, but why
2008/11/29 Brendan Eich [EMAIL PROTECTED]:
At the TC39 meeting two weeks ago in Kona, we had a brief bikeshedding
discussion about lambda syntax and why it matters.
Who would have thought a discussion about lambda syntax in JavaScript
would go over 120 posts while a simultaneous thread about
On Thu, Dec 4, 2008 at 6:10 PM, Brendan Eich [EMAIL PROTECTED] wrote:
On Dec 4, 2008, at 2:45 PM, Jon Zeppieri wrote:
2008/12/4 Breton Slivka [EMAIL PROTECTED]:
this may be a stupid question, but why? Is it really so impossible to
have λ(a,b,c){} ?
Last time I brought this up, Brendan
Brendan Eich wrote:
If we have to go to one character, though, I'd rather we use an ASCII
punctuation character, for the reasons given (hard to type, slight
incompatibility). But you λ fans need to help me here: how does one type
λ on a Mac laptop? How about on a standard Windows machine? Pick
On Dec 4, 2008, at 5:44 PM, Eugene Lazutkin wrote:
If you started to recap the history of this discussion, could you (or
anybody else in the know) verbalize following things:
1) What is the difference between the function and the lambda? I am
not
talking about their syntax, I want to
I thought this might be the answer. It's clearly too much to ask of
all lambda-coders and would-be lambda-coders in the world.
My two cents, perhaps I'm wrong and the Schemers and others will
switch their kbd configs. Or the code generators will rise and
exterminate lambda-coding humans.
On Fri, Dec 5, 2008 at 1:10 PM, Brendan Eich [EMAIL PROTECTED] wrote:
I thought this might be the answer. It's clearly too much to ask of all
lambda-coders and would-be lambda-coders in the world.
My two cents, perhaps I'm wrong and the Schemers and others will switch
their kbd configs. Or
On Dec 4, 2008, at 6:39 PM, Breton Slivka wrote:
On Fri, Dec 5, 2008 at 1:10 PM, Brendan Eich [EMAIL PROTECTED]
wrote:
I thought this might be the answer. It's clearly too much to ask of
all
lambda-coders and would-be lambda-coders in the world.
My two cents, perhaps I'm wrong and the
Hi Brendan,
Please read
http://wiki.ecmascript.org/doku.php?id=strawman:lambdas
There is a lot of discussion over whether it is necessary to introduce
syntax sugar instead of a lambda keyword, but is there any remaining
controversy over the semantics of lambdas in JavaScript, or is that
No, \ worse than '^' or '', why not use
function ^ Identifier ( parameters ) block for declaration
and use
^ IdentifierOpt ( parameters ) block for expression
ExpressionStatement ::= [lookahead !{ {, function, ^ }] CommaExpression
Okay -- so we agree. In that case, it's clear that your
Hi Brendan,
The main contention about lambdas ignoring syntax is whether the
completion-value creates a hazard that needs to be treated somehow, or
even judged as fatal to the proposal.
Completion value, like the last thing to be evaluated in the lambda?
What exactly is the nature of the
On Dec 4, 2008, at 7:45 PM, Michael Day wrote:
Hi Brendan,
The main contention about lambdas ignoring syntax is whether the
completion-value creates a hazard that needs to be treated somehow,
or even judged as fatal to the proposal.
Completion value, like the last thing to be evaluated
PROTECTED]
Cc: Eric Suen [EMAIL PROTECTED]; Maciej Stachowiak
[EMAIL PROTECTED]; es-discuss
es-discuss@mozilla.org
Sent: Wednesday, December 03, 2008 8:56 PM
Subject: Re: Allen's lambda syntax proposal
Brendan Eich wrote:
C# uses (a, b, c) = ... but in JS the comma operator makes that nasty
to parse
On 2008-12-02, at 20:32EST, Peter Michaux wrote:
I keep a list of all the X-ES3 compilers I encounter in the middle of
the following page
http://peter.michaux.ca/articles/compiling-down-to-javascript-1-5
Clarification on:
OpenLaszlo is the opposite direction: JavaScript compiled into
2008/12/2 Brendan Eich [EMAIL PROTECTED]:
I think the only candidates have to be of the form
^(a, b, c) {...}
(^ could be another character, but it seems to beat \ as others have noted),
Was there a problem with \ other than the fact that it can't easily be
turned into a binding form, à la
In that case, you have to rewrite the grammar from:
OptionalParameter ::= Parameter '=' NonAssignmentExpression[allowIn]
to
OptionalParameter ::= Parameter '=' NonAssignmentExpression[allowIn,noOR]
Make it necessary complicated.
In feature(ES4), ES may have OptionalParameter, that will cause
Despite my nostalgic longing for Smalltalk, I agree ;). But since the
purpose is to be friendlier to control abstraction patterns, it remains
important to have a *very* lightweight syntax for the no-parameter (thunk)
case. The parameter list between the ^ and the { should be optional.
Btw, I see
Brendan Eich wrote:
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| ... } ?
Can't resist a historical note (which I haven't seen mentioned, but
perhaps I missed
2008/12/3 Michael [EMAIL PROTECTED]:
If I understand the proposals correctly, then of the following e4x:
Why do you mention e4x? I'm not familiar with it but thought it only
adds XML literals to the language.
Peter
var doc = {{|a,b,c|...}(d,e,f)}
var doc = {^(a,b,c){...}(d,e,f)}
var
On Dec 3, 2008, at 10:45 AM, Steven Johnson wrote:
On 12/2/08 7:11 PM, Neil Mix [EMAIL PROTECTED] wrote:
How's this for a strawman: the choice is to follow either Objective-C
or Smalltalk. Given that Objective-C and JS share syntactical roots
in C, it makes more sense to follow the
2008/12/3 P T Withington [EMAIL PROTECTED]:
- prefix ^ might be confused with the infix operator of the same name
With semicolon insertion, isn't this a bigger problem?
The opening brace will need to be on the same line as the formals,
otherwise the syntax is ambiguous:
^(x) {
x = x * x
On Dec 2, 2008, at 6:57 PM, Brendan Eich wrote:
This loses almost all connection with the rest of the language.
Arguments are passed in a comma separated list. Wrapped in
parentheses. The Smalltalk hommage loses the parens but keeps the
commas. Any other separator is just wrong, sorry.
Summary of what I've read:
The syntax \(){} has a named lambda problem if the lambda name starts
with a 'u'. Depending on whitespace between the backslash and the
identifier seems like it will cause bugs
\u03c0(){}
\ u03c0(){}
The syntax ^(){} has a semicolon insertion ambiguity. What does
Yuh-Ruey Chen wrote:
Brendan Eich wrote:
C# uses (a, b, c) = ... but in JS the comma operator makes that
nasty to parse top-down. I think the only candidates have to be of
the form
^(a, b, c) {...}
(^ could be another character, but it seems to beat \ as others have
noted), or else the
2008/12/3 Yuh-Ruey Chen [EMAIL PROTECTED]:
The control abstractions just don't look right, regardless of which lambda
syntax we choose. I'd rather wait for a more powerful macro system, instead
of choosing the syntax based off how it would look in control abstractions.
I agree completely.
PROTECTED]
On Behalf Of Brendan Eich
Sent: Wednesday, December 03, 2008 12:52 PM
To: Steven Johnson
Cc: Neil Mix; Maciej Stachowiak; Eric Suen; es-discuss
Subject: Re: Allen's lambda syntax proposal
On Dec 3, 2008, at 10:45 AM, Steven Johnson wrote:
On 12/2/08 7:11 PM, Neil Mix [EMAIL PROTECTED] wrote
On Thu, Dec 4, 2008 at 9:28 AM, Michael [EMAIL PROTECTED] wrote:
This may be a stupid question, but is the current let expression syntax
defined in JavaScript 1.7 too fundamentally different from the sought out
lambda expression to be repurposed? Or would this wreak havoc on current
uses?
I
First, let expressions as implemented in JS1.7 are ambiguous in a
bottom up grammar. See
https://mail.mozilla.org/pipermail/es-discuss/2008-October/007890.html
Second, let statements and expressions in JS1.7 are evaluated when
reached. They are not implicitly quoted for later application.
On Dec 3, 2008, at 4:06 PM, Sam Ruby wrote:
2008/11/30 Brendan Eich [EMAIL PROTECTED]:
At the TC39 meeting two weeks ago in Kona, we had a brief
bikeshedding
discussion about lambda syntax and why it matters.
Has anybody given any thought to the C# (ECMA TC49) syntax?
Yes, it has come up
On Dec 3, 2008, at 6:18 PM, Maciej Stachowiak wrote:
x = x
+x
That is equivalent to
x = x + x;
so the case with ^ should not differ. (Were you testing in an
interactive REPL?)
That the case Peter showed:
x = x
^(){}
cannot be parsed as a bitwise-xor expression doesn't help in general,
On 12/03/2008 06:18 PM, Maciej Stachowiak wrote:
On Dec 3, 2008, at 1:23 PM, Peter Michaux wrote:
x = x
^(){}
I think this has only one possible meaning: an expression statement
consisting of an assignment of x to itself, followed by an expression
statement that creates an empty no-argument
Subject: Re: Allen's lambda syntax proposal
2008/12/3 P T Withington [EMAIL PROTECTED]:
- prefix ^ might be confused with the infix operator of the same name
With semicolon insertion, isn't this a bigger problem?
The opening brace will need to be on the same line as the formals
Suen [EMAIL PROTECTED]
Cc: Jon Zeppieri [EMAIL PROTECTED]; es-discuss
es-discuss@mozilla.org
Sent: Thursday, December 04, 2008 10:45 AM
Subject: Re: Allen's lambda syntax proposal
On Wed, Dec 3, 2008 at 9:36 PM, Eric Suen [EMAIL PROTECTED] wrote:
No,
^(x) is not a legal expression, so you
It even can be writen as:
Lambda ::= '' IdentifierOpt ParametersOpt Block
IdentifierOpt ::= %Empty
| PropertyIdentifier
ParametersOpt ::= %Empty
| '(' Parameters ')'
I suggest following grammar:
Lambda ::= '' '(' Parameters ')' Block
| '' Block //if no parameters
I can comfire that this
On Wed, Dec 3, 2008 at 9:52 PM, Eric Suen [EMAIL PROTECTED] wrote:
Because it is a xor expression, for lambda, it will be
x = x * x ^ ^ (a,b,c,d,e,f,g)
{
x
}
I don't understand what you're getting at. That's a syntax error. My example:
x = x * x
^(a,b,c,d,e,f,g)
{
x
}
is not a syntax
Yes, it doesn't contain a lambda expression, just like:
a = x
/x/i
is not same as:
a = x;
/x/i
they both right but has different meaning...
Because it is a xor expression, for lambda, it will be
x = x * x ^ ^ (a,b,c,d,e,f,g)
{
x
}
I don't understand what you're getting at. That's a
On Wed, Dec 3, 2008 at 7:16 PM, Eric Suen [EMAIL PROTECTED] wrote:
Yes, it doesn't contain a lambda expression, just like:
a = x
/x/i
is not same as:
a = x;
/x/i
they both right but has different meaning...
Is adding more confusion like this in the language desirable?
Peter
On Wed, Dec 3, 2008 at 10:16 PM, Eric Suen [EMAIL PROTECTED] wrote:
Yes, it doesn't contain a lambda expression, just like:
a = x
/x/i
is not same as:
a = x;
/x/i
they both right but has different meaning...
Okay -- so we agree. In that case, it's clear that your proposed syntax:
On Dec 2, 2008, at 5:31 AM, Aaron Gray wrote:
i still prefer 'lambda (a,b,c) { ... }' as it is readable to the
uninitiated and can then at least give a handle for someone to lookup.
I think the truly uninitiated would not find lambda any more obvious
in meaning than \ or ||.
Regards,
]; 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
On 2008-12-02, at 11:48EST, Maciej Stachowiak wrote:
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) { ... }
That's cute. Mnemonic for Λ (capital λ), also
On Dec 2, 2008, at 5:31 AM, Aaron Gray wrote:
i still prefer 'lambda (a,b,c) { ... }' as it is readable to the
uninitiated and can then at least give a handle for someone to lookup.
I think the truly uninitiated would not find lambda any more obvious in
meaning than \ or ||.
People can
: gmane.comp.lang.javascript.ecmascript4.general
To: Eric Suen [EMAIL PROTECTED]
Cc: Brendan Eich [EMAIL PROTECTED];
es-discuss [EMAIL PROTECTED]
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
On 1 Dec, 2008, at 10:18 PM, Peter Michaux wrote:
One problem is if the argument list needs to take two lambdas, then
where would the second lambda go? One inside the arguments list and
one after? Why is one lambda more important or deserving of a special
place compared with the other lambda?
2008/12/2 Jeff Watkins [EMAIL PROTECTED]:
Since the goal seems to be allowing control structures like Smalltalk
(yay!), how about specifying that one lambda that follows a function
invocation is passed as the final argument to the invocation.
Brendan seemed to reject the idea that this could
On Tue, Dec 2, 2008 at 10:36 AM, Aaron Gray [EMAIL PROTECTED]
wrote:
On Dec 2, 2008, at 5:31 AM, Aaron Gray wrote:
i still prefer 'lambda (a,b,c) { ... }' as it is readable to the
uninitiated and can then at least give a handle for someone to lookup.
I think the truly uninitiated would
Peter Michaux wrote:
2008/12/2 Jeff Watkins [EMAIL PROTECTED]:
Since the goal seems to be allowing control structures like Smalltalk
(yay!), how about specifying that one lambda that follows a function
invocation is passed as the final argument to the invocation.
Brendan seemed to reject
Maciej Stachowiak wrote:
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
I've been casually following this discussion, and I can't help but rail
against the inherent limitations of ES's C heritage.
From the control abstraction standpoint, although {||...} gets close to
that goal, the discrepancy from true {...} control syntax stands out
like a sore thumb to me. And
On Tue, Dec 2, 2008 at 4:08 PM, Yuh-Ruey Chen [EMAIL PROTECTED] wrote:
(As a side note, sometimes I wonder if all this talk about sugar is
moot, because I suspect more and more languages will start compiling
down to ES.)
I keep a list of all the X-ES3 compilers I encounter in the middle of
-
From: Maciej Stachowiak
[EMAIL PROTECTED]
Newsgroups: gmane.comp.lang.javascript.ecmascript4.general
To: Brendan Eich [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Tuesday, December 02, 2008 4:59 AM
Subject: Re: Allen's lambda syntax proposal
On Nov 29, 2008, at 10:30 PM, Brendan Eich wrote
On Tue, Dec 2, 2008 at 7:11 PM, Neil Mix [EMAIL PROTECTED] wrote:
How's this for a strawman: the choice is to follow either Objective-C or
Smalltalk.
Or Scheme which, after all, was the first Lisp with lexical scoping
and first-class lambdas.
Peter
Brendan Eich wrote:
// Instead of lambda (a, b, c) { ... }, why not:
{ |a, b, c| ... } ?
Looks like Ruby to me, so you know I love it. :)
Nice lambda syntax really matters. If that tool is too heavy, I only
use it half as often as I should.
Chris
On Mon, Dec 1, 2008 at 2:06 AM, Chris Pine [EMAIL PROTECTED] wrote:
Brendan Eich wrote:
// Instead of lambda (a, b, c) { ... }, why not:
{ |a, b, c| ... } ?
Looks like Ruby to me, so you know I love it. :)
Nice lambda syntax really matters. If that tool is too heavy, I only use it
half
Peter Michaux wrote:
On Mon, Dec 1, 2008 at 2:06 AM, Chris Pine [EMAIL PROTECTED] wrote:
Brendan Eich wrote:
// Instead of lambda (a, b, c) { ... }, why not:
{ |a, b, c| ... } ?
Looks like Ruby to me, so you know I love it. :)
Nice lambda syntax really matters. If that tool is too heavy, I
On 2008-11-30, at 01:30EST, Brendan Eich wrote:
// Instead of lambda (a, b, c) { ... }, why not:
{ |a, b, c| ... } ?
I would rather have a more literate syntax, lest we degenerate to
where practically any comic book blasphemy is a valid program.
(BTW, I'm pretty sure I have that same Byte
On 2008-12-01, at 11:30EST, Mark S. Miller wrote:
On Mon, Dec 1, 2008 at 7:31 AM, P T Withington [EMAIL PROTECTED] wrote:
On 2008-11-30, at 01:30EST, Brendan Eich wrote:
// Instead of lambda (a, b, c) { ... }, why not:
{ |a, b, c| ... } ?
I would rather have a more literate syntax, lest
On Mon, Dec 1, 2008 at 8:47 AM, P T Withington [EMAIL PROTECTED] wrote:
Eh? So:
function () {
var foo = 42;
{|| var foo = 3; }
return foo;
}
and:
function () {
var foo = 42;
{ var foo = 3; }
return foo;
}
Give the same answer?
No, because you forgot to call it.
On 2008-12-01, at 11:54EST, Mark S. Miller wrote:
On Mon, Dec 1, 2008 at 8:47 AM, P T Withington [EMAIL PROTECTED] wrote:
Eh? So:
function () {
var foo = 42;
{|| var foo = 3; }
return foo;
}
and:
function () {
var foo = 42;
{ var foo = 3; }
return foo;
}
Give the same answer?
No,
1 - 100 of 124 matches
Mail list logo
