Re: Allen's lambda syntax proposal

[Maciej Stachowiak]

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,
Maciej

___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Allen's lambda syntax proposal

[Maciej Stachowiak]

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
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Allen's lambda syntax proposal

[P T Withington]

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 'pointer-ish',  
implying an object reference.

___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: How much sugar do classes need?

[Mark Miller]

On Mon, Dec 1, 2008 at 12:01 PM, David-Sarah Hopwood
[EMAIL PROTECTED] wrote:
 Peter Michaux wrote:
 What is the motivation for choosing the string to?

 It is used in E to introduce a method.

 (It was also used in Logo to introduce a procedure declaration, but that
 may be a coincidence.)

Not a coincidence. E's use of to was inspired by Logo's.


 The problem is that functions are mutable, which we are stuck with for
 backward compatibility. But there is no such backward compatibility
 constraint on lambdas, which can and should be immutable. So, given
 Allen Wirfs-Brock's syntax for lambda, we can do something like:

  var self = {
method toString: {|| '' + self.getX() + ',' + self.getY() + ''},
method getX: {|| x},
method getY: {|| y},
field pubInstVar: 4,
const pubInstConst: -4,
  };
  return self;

 where the extensions to the object literal syntax used here are:
  - a 'field' modifier to declare a property non-[[Configurable]],
  - a 'const' modifier to declare a property non-[[Configurable]]
   and non-[[Writable]],
  - a 'method' modifier to declare a property non-[[Configurable]],
   non-[[Writable]] and non-[[Enumerable]].

 Note that modifiers on object literal properties do not need to be
 reserved keywords ('get' and 'set' are already in this category).

I like this a lot. However, I think using lambdas directly for methods
has a fatal flaw: wrong return binding. As Waldemar pointed out at
Kona, lambdas return their completion value, making them hazardous for
direct use in contexts other than control abstractions. When used as a
method, a lambda written only to bring about side effects may
inadvertently leak a shoulda-been-encapsulated-value to its caller.

If someone writing a lambda is thinking method, they may very well
write a return, which will actually cause a return from the closest
enclosing function. E has the same two levels of we expect for
Harmony: return binding vs completion value, where the first expands
to the second. But we generally use only the return-binding form for
methods, to avoid this leakage hazard. (As you recall, we learned this
lesson the hard way ;).)

-- 
Text by me above is hereby placed in the public domain

Cheers,
--MarkM
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Allen's lambda syntax proposal

[Aaron Gray]

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 google lambda they cannot google \, or ||. Also keywords 
seem better suited to Javascript syntax.


Aaron

___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Allen's lambda syntax proposal

[Eric Suen]

'~' is ambiguities usless you using two NO_LINE_BREAK like:

'~' NO_LINE_BREAK (...) NO_LINE_BREAK {...}

'.' may not looks good, but it does not introduce new token
like '\' or 'lambda'

Regards,

Eric Suen

- Original Message - 
From: Maciej Stachowiak [EMAIL PROTECTED]
Newsgroups: 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) {}

 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 

Re: Allen's lambda syntax proposal

[Jeff Watkins]

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?


I've been writing JS a long time and I don't frequently find myself  
wanting to pass more than one function/lambda to another function. On  
the (very) rare occasion when I do, I suspect I'm not calling a  
control-structure-like function. Then I'd be comfortable passing two  
lambdas as arguments.


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. You can  
write the invocation:


withNode(node, {|n| ... })

and I'll write it as:

withNode(node)
{ |n|
...
}


Some API designers won't like the trailing lambda syntax and some
will. Then we end up with inconsistent APIs.


I think if lambdas can be specified outside the parameter list, API  
designers will feel pressure from those who use their APIs to adopt  
the trailing lambda style. This would only be a significant issue when  
the API is expecting a single lambda.


And regarding using the full term lambda in the syntax, I think I'm  
not alone that I'd have a hard time adopting lambdas over functions  
without a significant improvement in syntax -- and changing the name  
from function to lambda isn't significant. Especially considering that  
the initial implementations of lambdas might not hold a significant  
performance improvement over functions.


Of course, it would also be super cool if I could write something like:

{ |n|

hide: function()
{
n.style.display='none';
},

show: function()
{
n.style.display='';
},

etc...
}

Of course if I didn't have to pay the cost of instantiating a new  
function for every object instance, that would make something like  
this worthwhile.


Jeff

___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Allen's lambda syntax proposal

[Peter Michaux]

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 be passed as the
first argument to a constructor, so that this could be explicitly
named, on the grounds that the parameter lists would not match. I
agree that parameter lists should match. I was just asking.

https://mail.mozilla.org/pipermail/es-discuss/2008-November/008203.html



If a trailing block outside the parameter list is passed as the last
argument, then what happens when there is a rest parameter as the last
argument in the parameter list? It gets a bit messy to determine if
the last argument passed in was the last argument of some rest
parameters or an optional trailing lambda.

Peter
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Allen's lambda syntax proposal

[Brian Kardell]

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 not find lambda any more obvious  in
 meaning than \ or ||.


 People can google lambda they cannot google \, or ||. Also keywords
 seem better suited to Javascript syntax.

 Aaron


Is the argument that the uninitiated should be able understand complex code
concepts via a google search of the thing that they don't understand?

There are already all kinds of things that one couldn't understand via a
simple google search for something in the code, and which people of various
levels of experience might experience:  Object literals come to mind or ||
and  as guard/default, ? as ternary if, or even ++ or %= and there
are plenty more things which might or might not have a readily identifiable
thing to allow someone to google for like default values, coercion rules, or
scoping concepts.

Google is an excellent tool, but I don't think that it's necessarily a great
way to interpret code into something understandable to the uninitiated.
 Doesn't seem like a good deciding factor.



 ___
 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

[David-Sarah Hopwood]

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 the idea that this could be passed as the
 first argument to a constructor, so that this could be explicitly
 named, on the grounds that the parameter lists would not match. I
 agree that parameter lists should match. I was just asking.
 
 https://mail.mozilla.org/pipermail/es-discuss/2008-November/008203.html
 
 
 
 If a trailing block outside the parameter list is passed as the last
 argument, then what happens when there is a rest parameter as the last
 argument in the parameter list? It gets a bit messy to determine if
 the last argument passed in was the last argument of some rest
 parameters or an optional trailing lambda.

Will ES-Harmony have labelled arguments? If it does then both of these
problems go away, since the block argument can have a standard label,
and similarly for the this argument.

-- 
David-Sarah Hopwood
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: How much sugar do classes need?

[Jon Zeppieri]

On Tue, Dec 2, 2008 at 1:54 PM, Peter Michaux [EMAIL PROTECTED] wrote:
 On Mon, Dec 1, 2008 at 12:01 PM, David-Sarah Hopwood
 [EMAIL PROTECTED] wrote:

  var self = {
method toString: {|| '' + self.getX() + ',' + self.getY() + ''},
method getX: {|| x},
method getY: {|| y},
field pubInstVar: 4,
const pubInstConst: -4,
  };
  return self;

 where the extensions to the object literal syntax used here are:
  - a 'field' modifier to declare a property non-[[Configurable]],
  - a 'const' modifier to declare a property non-[[Configurable]]
   and non-[[Writable]],
  - a 'method' modifier to declare a property non-[[Configurable]],
   non-[[Writable]] and non-[[Enumerable]].

 I don't think only a method would have the combination of attributes
 listed above.

Agreed.  The proposed names do not denote what they appear to denote.

 Also because functions are first class in JavaScript, I
 think of a function valued property as a field so don't like the name
 field. Also would method be able to be a lambda or function?

From David-Sarah's description, it seemed to me that 'method' merely
means that the property is non-configurable, non-writable, and
non-enumerable and has nothing to do with the 'type' (as it were) of
its value.  And that's a good example of how the proposed names are
misleading.


 There are 2^3 = 8 combinations of Configurable, Writable, Enumerable
 and potentially more attributes in the future. I'd prefer to control
 them independently. If multiple prefix modifiers are not appealing,
 what about some flags like the 'g' that can follow a regexp literal
 (e.g. /a/g)


 var self = {
  toString[]: {|| '' + self.getX() + ',' + self.getY() + ''},
  getX[]: {|| x},
  getY[]: {|| y},
  pubInstVar[WE]: 4,
  pubInstConst[E]: -4,
 };

I find this ugly, but I don't have any great ideas.  I do want to
point out, however, that one important combination is omitted in
David-Sarah's proposal (modifier names aside).  Private instance
variables would likely be represented as non-configurable,
non-enumerable, yet writable properties.  I'm guessing that 'x' and
'y' (which are suggested by, but left out of the examples above) would
fit that description.

-Jon




 If no brackets are included then it would be equivalent to [WEC] as
 that is backwards compatible (I think).

 I'm not sure I like this idea. It is just an idea.

 Peter
 ___
 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: How much sugar do classes need?

[Jon Zeppieri]

On Tue, Dec 2, 2008 at 2:35 PM, Jon Zeppieri [EMAIL PROTECTED] wrote:
 ... I do want to
 point out, however, that one important combination is omitted in
 David-Sarah's proposal (modifier names aside).  Private instance
 variables would likely be represented as non-configurable,
 non-enumerable, yet writable properties.  I'm guessing that 'x' and
 'y' (which are suggested by, but left out of the examples above) would
 fit that description.

OK -- I just revisited the older messages in the thread.  'x' and 'y'
are lexically bound (by the constructor function).  So, ignore the
above...
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: How much sugar do classes need?

[Mark Miller]

On Tue, Dec 2, 2008 at 11:35 AM, Jon Zeppieri [EMAIL PROTECTED] wrote:
 var self = {
  toString[]: {|| '' + self.getX() + ',' + self.getY() + ''},
  getX[]: {|| x},
  getY[]: {|| y},
  pubInstVar[WE]: 4,
  pubInstConst[E]: -4,
 };

 I find this ugly, but I don't have any great ideas.  I do want to
 point out, however, that one important combination is omitted in
 David-Sarah's proposal (modifier names aside).  Private instance
 variables would likely be represented as non-configurable,
 non-enumerable, yet writable properties.  I'm guessing that 'x' and
 'y' (which are suggested by, but left out of the examples above) would
 fit that description.

x and y above are indeed private instance variables, but that's
precisely because they are not properties -- they are normal variables
lexically captured by the functions/lambdas which use them.


-- 
Text by me above is hereby placed in the public domain

Cheers,
--MarkM
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Allen's lambda syntax proposal

[David-Sarah Hopwood]

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 already an operator; I tend to think not, because + and -
 manage to be both unary and binary operators without ambiguity.

Correct, it would be grammatically unambiguous. It might still be
mildly confusing, though (unlike unary minus, which is related to
subtraction by -x = 0-x, lambda abstraction is unrelated to bitwise
exclusive-or). But any notation for lambdas is likely to be mildly
confusing to the uninitiated.

 ^ also has a slight resemblance to the greek lambda, which is the
 reason Haskell uses \.

^ also has some historical relevance:

Felice Cardone, J. Roger Hindley,
History of Lambda-calculus and Combinatory Logic
2006, Swansea University Mathematics Department
Research Report No. MRRS-05-06.
http://www-maths.swan.ac.uk/staff/jrh/papers/JRHHislamWeb.pdf

# (By the way, why did Church choose the notation λ? In [Church, 1964, §2]
# he stated clearly that it came from the notation x̂ used for
# class-abstraction by Whitehead and Russell, by first modifying x̂ to
# ∧x to distinguish function-abstraction from class-abstraction, and
# then changing ∧ to λ for ease of printing. This origin was also
# reported in [Rosser, 1984, p.338]. On the other hand, in his later years
# Church told two enquirers that the choice was more accidental: a symbol
# was needed and λ just happened to be chosen.)

[Church, 1964] A. Church, 7 July 1964. Unpublished letter to Harald Dickson.

[Rosser, 1984] J. B. Rosser. Highlights of the history of the lambda
calculus. Annals of the History of Computing, 6:337–349, 1984.


[If your email client doesn't display the above correctly:
  x̂ is an x with a hat operator (similar to a circumflex) above it.
  ∧ is an upward-pointing wedge.
  λ is a lowercase Greek lambda.]

-- 
David-Sarah Hopwood


___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: How much sugar do classes need?

[Jon Zeppieri]

On Tue, Dec 2, 2008 at 1:54 PM, Peter Michaux [EMAIL PROTECTED] wrote:

 var self = {
  toString[]: {|| '' + self.getX() + ',' + self.getY() + ''},
  getX[]: {|| x},
  getY[]: {|| y},
  pubInstVar[WE]: 4,
  pubInstConst[E]: -4,
 };

 If no brackets are included then it would be equivalent to [WEC] as
 that is backwards compatible (I think).

 I'm not sure I like this idea. It is just an idea.


Another just an idea:

#{ ... } is an object initializer where all of the initialized
properties are non-configurable.
'enum' (or something similar) is a property modifier that makes the
property enumerable.
'const' continues to have the same meaning (non-configurable and
non-enumerable).  Where 'const' appears inside #{ ... }, the
non-configurable aspect is redundant.

var self = #{
  const toString: {|| '' + self.getX() + ',' + self.getY() + ''},
  const getX: {|| x},
  const getY: {|| y},
  enum pubInstVar: 4,
  enum const pubInstConst: -4
};

It's more verbose than Peter's syntax, but it doesn't overload the
array index syntax, and although the #{ ... } initializer
unfortunately introduces new syntax, I think its functionality is
genuinely (and generally) useful.  I'd imagine that most real-world
uses of { ... } could be replaced by #{ ... }, since initialized
properties are usually expected to stick around.

On the other hand:

  enum const get foo () { ... }

... is odd.

-Jon
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: How much sugar do classes need?

[Peter Michaux]

On Tue, Dec 2, 2008 at 1:40 PM, Jon Zeppieri [EMAIL PROTECTED] wrote:

 #{ ... } is an object initializer where all of the initialized
 properties are non-configurable.

The use of '#' makes me think of reader macros. I like the idea of
reader macros for ES. (I don't know if '#' can be used because of
sharp variables which I believe are part of JavaScript.)

I think it would be good to be able to use custom quotes on regular
expressions and strings

#r(some/regexp/containing/slashes)

#s/a string containing  quotation ' marks/


 'enum' (or something similar) is a property modifier that makes the
 property enumerable.
 'const' continues to have the same meaning (non-configurable and
 non-enumerable).  Where 'const' appears inside #{ ... }, the
 non-configurable aspect is redundant.

 var self = #{
  const toString: {|| '' + self.getX() + ',' + self.getY() + ''},
  const getX: {|| x},
  const getY: {|| y},
  enum pubInstVar: 4,
  enum const pubInstConst: -4
 };

 It's more verbose than Peter's syntax, but it doesn't overload the
 array index syntax,

I used [] just as an example. It could have been many different separators.

 and although the #{ ... } initializer
 unfortunately introduces new syntax, I think its functionality is
 genuinely (and generally) useful.  I'd imagine that most real-world
 uses of { ... } could be replaced by #{ ... }, since initialized
 properties are usually expected to stick around.

 On the other hand:

  enum const get foo () { ... }

 ... is odd.

I think if there are to be modifiers than just have the modifiers and
not the #{}. Having all the modifiers with the property seems like a
better way to go to me. Also what if #{} is used to create the object
and later a property is added and is to be configurable? Is that
possible? Either decision seems arbitrary.

If there are going to be modifiers config, enum, and const then
there may be no harm in having other modifiers which represent a
combination of these modifiers (like the suggestions of field and
method though I don't really like those names for the reasons I
wrote before.)

Peter
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: How much sugar do classes need?

[Jon Zeppieri]

On Tue, Dec 2, 2008 at 4:58 PM, Peter Michaux [EMAIL PROTECTED] wrote:


 I think if there are to be modifiers than just have the modifiers and
 not the #{}. Having all the modifiers with the property seems like a
 better way to go to me.

That seems fine to me, too.  The #{ ... } idea just struck me, because
I realized that it pretty well captures what I actually *mean* when I
use { ... }.


 Also what if #{} is used to create the object
 and later a property is added and is to be configurable? Is that
 possible? Either decision seems arbitrary.

Yes, and I don't consider that arbitrary, at all.  The meaning of

  obj.foo = bar;

can't be dependent upon the mechanism used to create obj.

Now, if #{ ... } were to seal the object, then obviously you couldn't
add a new property to it.  While sealed (and frozen, for that matter)
initializers would be useful in places, just enforcing
non-configurability of the initial set of properties seems like a
reasonable trade-off between general usefulness (like I said, I bet
that most uses of { ... } could be replaced by #{ ... } without a
problem) and optimizer-friendliness.  (I'm thinking of Mark's number
(6) from earlier in this thread.)

Of course, there could also be initializers for sealed and frozen
objects.  E.g., #s{ ... } and #f{ ... } -- or whatever.  And these
would be more optimizer-friendly and less generally useful than #{ ...
}.  And each would introduce new syntax.  I'm in the minimize new
syntax camp.



 If there are going to be modifiers config, enum, and const then
 there may be no harm in having other modifiers which represent a
 combination of these modifiers (like the suggestions of field and
 method though I don't really like those names for the reasons I
 wrote before.)

Well, I think it's just a good practice to keep the set of modifiers
(and new syntax, in general) small.

-Jon
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Allen's lambda syntax proposal

[Yuh-Ruey Chen]

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 others have already pointed out the rest
params issue. I think it would be best to just stick with the functional
standpoint - lambdas as lightweight functions. Solving the control
abstraction should be dealt with in another less hacky way. There are
languages that can integrate lambdas easily with control abstraction;
unfortunately, ES is not one of them.

(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.)
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Allen's lambda syntax proposal

[Peter Michaux]

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
the following page

http://peter.michaux.ca/articles/compiling-down-to-javascript-1-5

This list has grown quite long with the majority of popular and
revered languages included. I wonder how many companies are using
these technologies and if that group is growing very quickly. ES is
good enough for most developers that I think the attraction is low
given the extra difficulties in development process and compiled code
speed (i.e. trampolines for tail calls are slow.)

If ES is the byte code of the browser then the better ES is, the
better the compiled code can be. Tail calls and continuations would be
valuable additions to ES. Threads are probably a trickier issue. If
these features cannot be added to ES directly then it would be great
if ES ran on a VM which exposed these features. Then all languages
could compile to that VM's byte code. I vaguely recall a web page
where Brendan Eich listed some of these features as part of JavaScript
3 (perhaps ES5). I can't find the page at the moment. The really
unfortunate part is the time lines to reach such goals are likely very
long...available in 95% of browsers in the year 2020? Who knows?

Peter
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Allen's lambda syntax proposal

[Brendan Eich]

On Dec 2, 2008, at 6:26 PM, Eric Suen wrote:


I really don't think prefix is neccessary, what about:

(a;b;c) {...}

or

(a:b:c) {...}

2nd one may have problem with '::' or TypedIdentifier in ES4.


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.


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.


/be




Regards,

Eric Suen

- Original Message -
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:

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

[Peter Michaux]

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
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss