Re: Allen's lambda syntax proposal

classic Classic list List threaded Threaded
89 messages Options
12345
Reply | Threaded
Open this post in threaded view
|

Re: Allen's lambda syntax proposal

Brendan Eich-3
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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Allen's lambda syntax proposal

David-Sarah Hopwood
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 Smalltalky
>>
>> { |a, b, c| ... }
>>
>> At this point we need a bake-off, or a convincing argument against the
>> unusual vertical bar usage.
>
> Here's a possible technical issue that might not apply to ES: Ruby
> blocks params can't have default arguments according to
> http://eigenclass.org/hiki.rb?Changes+in+Ruby+1.9#l9 :
>
>     The new syntax allows to specify default values for block arguments,
>     since
>
>      {|a,b=1| ... }
>
>     is said to be impossible with Ruby's current LALR(1) parser, built
>     with bison.

There's an ambiguity here that is independent of what kind of parser
is used (I don't know whether it is the same issue as in Ruby).
Consider:

  {|a=1|2, b|c}

Is the argument list (a = 1|2, b) with body {c}, or is it
(a = 1) with body {2, b|c}?

This ambiguity could be resolved by restricting expressions used as
default argument initialisers, but it is not clear why they should
be restricted, given that other possible concrete syntaxes for
lambda do not have this problem.

IMHO this does count as a "convincing argument against the unusual
vertical bar usage", if we want default arguments (and I think we do).

However, I'd like to suggest that it may be premature to be deciding
on the concrete syntax of lambda, without knowing its abstract syntax.
(The issue that MarkM raised about unintentionally leaking a value
that happens to be evaluated in tail position, for example, needs to
be dealt with at the abstract syntax level.) The same point applies
to the syntax of object literals.

That will require some notation for discussing abstract syntax, on
which I'll start another thread.

--
David-Sarah Hopwood
_______________________________________________
Es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Allen's lambda syntax proposal

David-Sarah Hopwood
In reply to this post by Brendan Eich-3
Yuh-Ruey Chen wrote:

> Eric Suen wrote:
>> In feature(ES4), ES may have OptionalParameter, that will cause trouble
>>
>> { |a ,b = 1 | c | d | e | f }
>>
>> is
>>
>> { (|a ,b = 1 |) c | d | e | f }
>>
>> or
>>
>> { (|a ,b = 1 | c) | d | e | f }
>>
>> Regards,
>>
>> Eric Suen
>>  
>
> That should be a syntax error. Parenthesis should be required in that
> case to avoid ambiguity: {|a, b = (1 | c)| ... }

Yuck. The restrictions on 'in' are bad enough; this is essentially the
same kind of ambiguity in another context. Requiring expressions
containing '|' to be parenthesized would impose the same degree of
grammar complexity overhead again as that imposed by 'NoIn':

  ArgumentInitialiser :
    = ExpressionNoBar
    = ( Expression )

... unless all default argument initialisers have to be parenthesized,
but that is just ugly.

--
David-Sarah Hopwood

_______________________________________________
Es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Allen's lambda syntax proposal

David-Sarah Hopwood
In reply to this post by Brendan Eich-3
Jon Zeppieri wrote:

> 2008/12/3 P T Withington <[hidden email]>:
>> - 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
>   ^(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.

> Will semicolon insertion be illegal inside a lambda body?

That's worth considering. It does not prevent lambdas from being used
to desugar other constructs, because semicolon insertion would be
performed on the original program before desugaring.

--
David-Sarah Hopwood

_______________________________________________
Es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Allen's lambda syntax proposal

P T Withington
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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Allen's lambda syntax proposal

Jon Zeppieri-2
In reply to this post by David-Sarah Hopwood
On Thu, Dec 4, 2008 at 3:23 PM, David-Sarah Hopwood
<[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Allen's lambda syntax proposal

David-Sarah Hopwood
In reply to this post by Brendan Eich-3
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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Allen's lambda syntax proposal

David-Sarah Hopwood
In reply to this post by David-Sarah Hopwood
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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Allen's lambda syntax proposal

Brendan Eich-3
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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Allen's lambda syntax proposal

Breton Slivka
In reply to this post by David-Sarah Hopwood
On Fri, Dec 5, 2008 at 7:49 AM, David-Sarah Hopwood
<[hidden email]> wrote:

> 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

this may be a stupid question, but why? Is it really so impossible to
have λ(a,b,c){}  ?
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. Nearly all computers on the planet have a greek alphabet
installed on them. And keep in mind, we're not designing a language
for tomorrow. We're designing a language for 10 years from now. λ
could be way more convenient to enter by then, particularly if it's in
an upcoming spec for a programming language.

I admit this seems ludicrous at its face, but admittedly I have not
really seen the arguments against λ as an abbreviated lambda syntax
yet.
_______________________________________________
Es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Allen's lambda syntax proposal

Brendan Eich-3
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/glasgow-haskell-users@.../msg15581.html

It's still too hard to type.

/be

_______________________________________________
Es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Allen's lambda syntax proposal

Jon Zeppieri-2
In reply to this post by Breton Slivka
[oops, sent from the wrong address...]

2008/12/4 Breton Slivka <[hidden email]>:
>
> 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 <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Allen's lambda syntax proposal

Breton Slivka
In reply to this post by Brendan Eich-3
On Fri, Dec 5, 2008 at 9:35 AM, Brendan Eich <[hidden email]> 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/glasgow-haskell-users@.../msg15581.html
>
> It's still too hard to type.
>
> /be
>
>

http://picasaweb.google.com/eileen.world.traveler/EileenBestOfGreece#5139474493916668850
_______________________________________________
Es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

RE: Allen's lambda syntax proposal

Michael-125
In reply to this post by Jon Zeppieri-2
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: [hidden email] [mailto:[hidden email]]
On Behalf Of Jon Zeppieri
Sent: Thursday, December 04, 2008 4:46 PM
To: [hidden email]
Subject: Re: Allen's lambda syntax proposal

[oops, sent from the wrong address...]

2008/12/4 Breton Slivka <[hidden email]>:
>
> 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 <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
Es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Allen's lambda syntax proposal

Brendan Eich-3
In reply to this post by Jon Zeppieri-2
On Dec 4, 2008, at 2:45 PM, Jon Zeppieri wrote:

> 2008/12/4 Breton Slivka <[hidden email]>:
>>
>> 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...


> On Thu, Dec 4, 2008 at 5:35 PM, Brendan Eich <[hidden email]>  
> 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.

True enough. And 'lambda' is likelier to be in use in web JS as an  
identifier than λ, at a guess.

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.

/be
_______________________________________________
Es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Allen's lambda syntax proposal

Peter Michaux
In reply to this post by Brendan Eich-3
2008/11/29 Brendan Eich <[hidden email]>:
> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Allen's lambda syntax proposal

Jon Zeppieri-2
In reply to this post by Brendan Eich-3
On Thu, Dec 4, 2008 at 6:10 PM, Brendan Eich <[hidden email]> wrote:

> On Dec 4, 2008, at 2:45 PM, Jon Zeppieri wrote:
>
>> 2008/12/4 Breton Slivka <[hidden email]>:
>>>
>>> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Allen's lambda syntax proposal

Felix-54
In reply to this post by Brendan Eich-3
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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Allen's lambda syntax proposal

Eugene Lazutkin
In reply to this post by Brendan Eich-3
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.

2) Why is it important for a lambda to have an optional name? What's
wrong with using a function, if we want a name? IMHO lambda should have
the minimalistic syntax.

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.

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.

Thanks,

Eugene

Mark S. Miller wrote:

> On Wed, Dec 3, 2008 at 7:25 PM, Jon Zeppieri
> <[hidden email]
> <mailto:[hidden email]>> 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 conte nders saddled with "binary
> operator"ness, drop back and concede. "\" has taken the lead....
>
> --
>    Cheers,
>    --MarkM
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
Es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Allen's lambda syntax proposal

Brendan Eich-3
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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
12345