Re: Allen's lambda syntax proposal
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 has different meaning...
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.
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Allen's lambda syntax proposal
My example:
x = x * x
^(a,b,c,d,e,f,g)
{
x
}
is not a syntax error, but it also (unfortunately) doesn't contain a
lambda expression. Or am I missing something?
Or a bit more obvious than the use of the comma-operator:
As soon as named lambdas are introduced (the weak spot on the \
proposal), you'll get big problems with the ^ proposal, too.
Consider the following snippet which is valid Javascript code, but
certainly not a lambda expression.
var f = function (){return 8;}
var x = 5
^f(x) { x=x*x }
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
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
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Revisiting Decimal
Sam Ruby wrote: So now the question is: where are we now? For the time being, concentrating on other things that will be in ES3.1. That was the main point of removing Decimal, no? -- David-Sarah Hopwood ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
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 somehow and
didn't test which way. I don't think it matters much which way, since
you can avoid any such problems in your own code by using semicolons
for line endings.
That the case Peter showed:
x = x
^(){}
cannot be parsed as a bitwise-xor expression doesn't help in
general, if we do not want to mandate bottom-up parsing (we don't).
I think it would be fine for this case to be a syntax error.
Regards,
Maciej
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
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
the initial parameter list is in fact a parameter list or a comma
expression.
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
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.
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) are rooting for || because of its
previous historic performances. But || trips up over ambiguities not
present on its original track. ^ is now in the lead. Oh no! It trips on a
different ambiguity. This track seems riddled with more ambiguities than any
of these contenders have ever trained on. Seeing ^ stumble, and other
contenders saddled with binary operatorness, drop back and concede. \
has taken the lead
--
Cheers,
--MarkM
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
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) are rooting for || because of its previous historic performances. But || trips up over ambiguities not present on its original track. ^ is now in the lead. Oh no! It trips on a different ambiguity. This track seems riddled with more ambiguities than any of these contenders have ever trained on. Seeing ^ stumble, and other contenders saddled with binary operatorness, drop back and concede. \ has taken the lead I have my money on lambda. I'm thinking it has the endurance necessary. It has already lasted longer in history than all the others. Peter ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
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 parse an unbounded number of characters to determine if
the initial parameter list is in fact a parameter list or a comma
expression.
Right -- especially if one includes destructuring parameters.
Typically a top-down cover grammar is parsed, and then disamiguated
based on right context after the AST is built, with any adjustments to
the AST encoding made retrospectively. This can get ugly.
Worse, as Waldemar pointed out, you can end up with a failure to
backtrack and find the valid sentential form that a bottom up parser
would find via shifting and reducing.
Combined, this says to me that the C# syntax is no-go for JS.
/be
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
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 initialization/assignment to preclude the =/== trap, or say, )\ for λ, and forcing camelCasing or carpal_tunnel_syndrome upon everyone who prefers descriptive-symbol-names...) /whinge ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
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 the spec
correctly, no semicolon would be inserted, and the whole thing would
be a syntax error. The offending token here is '{', but it's not
separated from the previous token -- namely, ')' -- by at least one
LineTerminator.
At any rate, it's a problem.
-Jon
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Revisiting Decimal
Brendan Eich wrote: On Dec 4, 2008, at 10:22 AM, David-Sarah Hopwood wrote: Sam Ruby wrote: So now the question is: where are we now? For the time being, concentrating on other things that will be in ES3.1. That was the main point of removing Decimal, no? es-discuss@mozilla.org has more bandwidth than singular focus on 3.1. OK, but there is no longer any current detailed spec for Decimal to comment on. I think the only major outstanding semantic issue was wrapper objects; apart from that, the devil was in the detail of spec wording. -- David-Sarah Hopwood ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
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 we can use for the modern equivalent of typographical reasons. -- David-Sarah Hopwood ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
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 you might expect. The semicolons would be inserted in this example
as follows:
^(x) {
x = (x * x)^(a, b, c, d, e, f, g);
{ x; }
};
Arguably, the problem here is that semicolon insertion is and always
was a bad idea.
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.
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.
--
David-Sarah Hopwood
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Revisiting Decimal
On Dec 4, 2008, at 12:39 PM, David-Sarah Hopwood wrote: Brendan Eich wrote: On Dec 4, 2008, at 10:22 AM, David-Sarah Hopwood wrote: Sam Ruby wrote: So now the question is: where are we now? For the time being, concentrating on other things that will be in ES3.1. That was the main point of removing Decimal, no? es-discuss@mozilla.org has more bandwidth than singular focus on 3.1. OK, Good, since we have harmonious energy for lambda syntax on this list (you do, at any rate -- so do I, don't get me wrong -- but let's play fair with Decimal for Harmony as well as Lambda for Harmony). but there is no longer any current detailed spec for Decimal to comment on. Sam pointed that out too, and directed everyone to his test- implementation results page: http://intertwingly.net/stories/2008/09/20/estest.html Indeed we still have an open issue there ignoring the wrapper one: I think the only major outstanding semantic issue was wrapper objects; apart from that, the devil was in the detail of spec wording. No, the cohort/toString issue remains too (at least). /be ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
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 bugzilla.mozilla.org bug on file). But is it required for web interop? If IE JScript does it and has since the old days, then the default answer has to be yes, and we should think about specifying the de- facto standard. /be ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Revisiting Decimal
2008/12/4 Brendan Eich [EMAIL PROTECTED]: Sam pointed that out too, and directed everyone to his test-implementation results page: http://intertwingly.net/stories/2008/09/20/estest.html Indeed we still have an open issue there ignoring the wrapper one: I think the only major outstanding semantic issue was wrapper objects; apart from that, the devil was in the detail of spec wording. No, the cohort/toString issue remains too (at least). With a longer schedule, I would like to revisit that; but as of Redmond, we had consensus on what that would look like in the context of a 3.1 edition. From where I sit, I find myself in the frankly surreal position that we are in early December, and there are no known issues of consensus, though I respect that David-Sarah claims that there is one on wrappers, and I await his providing of more detail. /be - Sam Ruby ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
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 Lambda characters are not in the BMP: http://www.mail-archive.com/[EMAIL PROTECTED]/msg15581.html It's still too hard to type. /be ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
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? 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 not that much trouble
to remap a key, and you can always keep lambda(a,b,c){} as a more
verbose but more accessable alternative. IDEs could make a macro out
of it so you wouldn't even have to bother with going to the trouble of
remapping.
Exactly what I wrote then.
I admit this seems ludicrous at its face, but admittedly I have not
really seen the arguments against λ as an abbreviated lambda syntax
yet.
Well aside from the random guy doesn't know how to map a key problem
(which is perfectly true), I could see some character set issues in
the field.
On Thu, Dec 4, 2008 at 5:35 PM, 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 allows Unicode identifiers, including Greek
Lambda.
Also including the word 'lambda' -- but that hasn't stopped it from
being seriously considered.
-Jon
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
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 allows Unicode identifiers, including Greek Lambda. Other Mathematical Lambda characters are not in the BMP: http://www.mail-archive.com/[EMAIL PROTECTED]/msg15581.html It's still too hard to type. /be http://picasaweb.google.com/eileen.world.traveler/EileenBestOfGreece#5139474493916668850 ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: Allen's lambda syntax proposal
For some reason I'm reminded of this quote:
APL, in which you can write a program to simulate shuffling a deck of cards
and then dealing them out to several players in four characters, none of
which appear on a standard keyboard. David Given
-Original Message-
From: [EMAIL PROTECTED] [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? 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 not that much trouble
to remap a key, and you can always keep lambda(a,b,c){} as a more
verbose but more accessable alternative. IDEs could make a macro out
of it so you wouldn't even have to bother with going to the trouble of
remapping.
Exactly what I wrote then.
I admit this seems ludicrous at its face, but admittedly I have not
really seen the arguments against λ as an abbreviated lambda syntax
yet.
Well aside from the random guy doesn't know how to map a key problem
(which is perfectly true), I could see some character set issues in
the field.
On Thu, Dec 4, 2008 at 5:35 PM, 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 allows Unicode identifiers, including Greek
Lambda.
Also including the word 'lambda' -- but that hasn't stopped it from
being seriously considered.
-Jon
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
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 class syntax has had little attention outside a handful of posters? Would this have been reverse 10 years ago? Sign of the paradigm shift? Maybe folks want an immutable cons cells too? Modern attention span? Peter ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
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 made fun of me on a podcast. :(
Not you personally! I hope that was at least a :-/ emoticon...
Oops. You see the typographical limitations we're still saddled with?
The mock-wounded :( and the actually-wounded :( aren't slated to have
distinct code points until Unicode 17.
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 a Linux and
lay the clues on there, too.
I'm a lot more likely to do this within emacs (or an editor, in
general) than at the system / window system level. Anyhow, ASCII
punctuation is great, if we can settle on a candidate.
-Jon
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
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 a Linux and lay the clues on there, too. you can add a greek keyboard to your input methods, and set up a kb shortcut to switch easily. like, for mac osx: system preferences, international, input menu. enable greek keyboard. enable show input menu in menu bar. click on keyboard shortcuts. in input menu, enable select the next input source, assign it a shortcut that doesn't conflict with anything you use, like maybe option-space. then, to type lambda, type option-space until you're at the greek flag, then type lowercase-L (on u.s. qwerty), windows is pretty similar to osx, it's in regional and language options I think modern linux is also similar, but I'm not near one at the moment. ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
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 understand the semantic
difference, if there is any.
Please read
http://wiki.ecmascript.org/doku.php?id=strawman:lambdas
2) Why is it important for a lambda to have an optional name?
It may not be.
What's
wrong with using a function, if we want a name? IMHO lambda should
have
the minimalistic syntax.
Minimalistic does not define itself. The question is what is the
minimal syntax given various constraints.
Church's Lambdas take one argument only. One can curry by hand. Why
isn't that the minimum minimum?
3) Why is it important to be able to specify parameter defaults in
lambda? Again, it looks like an extra sugar to me that can be
covered by
a function with parameter defaults.
See
https://mail.mozilla.org/pipermail/es-discuss/2008-October/007715.html
Also consider that default parameters are a convenience we want
lambdas to have if we believe functions should be avoided for much
lambda-coding by hand. The countervailing argument is that lambdas
have unintended completion value hazards, but Schemers and others
don't worry about these and would prefer not to have to run back to
functions and lose Tennent's Correspondence Principle every time
default parameters beckon.
The reason I ask is a lot of discussion is going around but if it
has a
name and but if it has a default. If it doesn't have a name I would
be satisfied personally with \(a, b) {...} --- it doesn't clash with
anything. Or even with \(a, b) expr.
You're right to question name to rescue \, but trying to minimize
lambdas won't save all the proposed syntaxes. We're making progress in
finding some to be in trouble, if not fatally flawed.
/be
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
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. But I doubt it. /be On Dec 4, 2008, at 5:44 PM, Felix wrote: 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 a Linux and lay the clues on there, too. you can add a greek keyboard to your input methods, and set up a kb shortcut to switch easily. like, for mac osx: system preferences, international, input menu. enable greek keyboard. enable show input menu in menu bar. click on keyboard shortcuts. in input menu, enable select the next input source, assign it a shortcut that doesn't conflict with anything you use, like maybe option-space. then, to type lambda, type option-space until you're at the greek flag, then type lowercase-L (on u.s. qwerty), windows is pretty similar to osx, it's in regional and language options I think modern linux is also similar, but I'm not near one at the moment. ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
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 the code generators will rise and exterminate lambda-coding humans. But I doubt it. /be approaching it from the other side of the question, it seems that people with german keyboards would have a similarly difficult time with the pipe character. example: http://forums.macosxhints.com/archive/index.php/t-29410.html It's the same issue with possibly any of the other symbols that have been discussed for the syntax. It doesn't really matter what you pick. If it's not lambda, you're inconveniencing someone. ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
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 Schemers and others will switch their kbd configs. Or the code generators will rise and exterminate lambda-coding humans. But I doubt it. /be That's why you'd map it to l tab in your ide. I don't have an ide -- March has some, but they bode ill :-P. Seriously, of course most users could figure out how to inject a Greek Lambda, but add up all that effort imposed on probably thousands to millions. It's an imposition. It is not a cost free good. Why is it so important to use a non-ASCII character? Also, you wouldn't be inconveniencing all lambda coders in the world. Only the ones without greek keyboards. Are there just not enough greek javascripters to matter? Heh. While I would like to think so, I doubt it. But you never know... /be ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
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 considered settled at this point? (To throw some more kerosene on the syntax fire, I would point out that fun for function nicely resembles var for variable: var x = fun y z = y + z; but it's not big deal :) Best regards, Michael -- Print XML with Prince! http://www.princexml.com ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
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 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.
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) are rooting for || because of its
previous historic performances. But || trips up over ambiguities not
present on its original track. ^ is now in the lead. Oh no! It trips on a
different ambiguity. This track seems riddled with more ambiguities than any
of these contenders have ever trained on. Seeing ^ stumble, and other
contenders saddled with binary operatorness, drop back and concede. \
has taken the lead
--
Cheers,
--MarkM
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
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 hazard? (To throw some more kerosene on the syntax fire, I would point out that fun for function nicely resembles var for variable: var x = fun y z = y + z; but it's not big deal :) Not bad but you lost the necessary (destructuring, default parameters) parenthesized formal list. Right, an arguments list should still look like an arguments list: var x = fun (y, z) = y + z or with an identifier: var x = fun fact(n) = (x 2 ? 1 : n * fact(n-1)) I toyed with 'fun' instead of 'function' in 1995 but it would have been a misfit in the Java-esque/C-like keyword set, even with 'var' included. In an alternate universe, you might have used 'method' for functions with a 'this' value, saving two characters and the name function for real functions :) Cheers, Michael -- Print XML with Prince! http://www.princexml.com ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
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 in the lambda?
What exactly is the nature of the hazard?
Functional programming favors using completion values -- function call
results propagate back up naturally this way. Chaining, filters, etc.
all work the way you want. Here's the Y combinator:
const fact = lambda(proc) {
return lambda (n) { (n = 1) ? 1 : n * proc(n-1); }
}
const Y = lambda(outer) {
const inner = lambda (proc) {
outer(lambda (arg) { proc(proc)(arg); });
}
inner(inner);
}
print(5! is + Y(fact)(5));
Adding return keywords just adds overhead, noise. One might even want
to get rid of the curly braces around lambda bodies, but the only way
to do it in the ES grammar and avoid ambiguity is to replace braces
with mandatory parentheses.
On the other hand, much JS on the web is imperative, and a lot uses a
mixed functional/imperative style. Often the last value in a function
is not the return value you want callers to be able to get, and with
functions all is well: falling off the end returns undefined.
But with lambdas, falling off the end returns the last statement's
completion value. This means people will have to write
lambda (secret) { compute(secret); void 0; }
and similar. Of course too few will remember to do this, so implicit
return values will tend to leak.
How severe a problem this might be is arguable, but we don't want to
gamble. We want user feedback based on trial implementations, and
other convincing evidence for or against.
/be
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
