RE: grammar update

2008-04-02 Thread Lars Hansen 
Looks like those restrictions (condition only at the end, only 'for',
'for each',
and 'if' clauses) originate in Brendan's original (too-sketchy)
proposal, see
the Comprehensions section of this page:

http://wiki.ecmascript.org/doku.php?id=proposals:iterators_and_generator
s

IMO we're looking for simple and useful comprehensions for ES4.  I
think extensions like the ones you are suggesting, though clearly
useful,
should be prototyped elsewhere before going into the language spec, or
at a minimum, be presented in a better developed proposal.

--lars

 -Original Message-
 From: [EMAIL PROTECTED] 
 [mailto:[EMAIL PROTECTED] On Behalf Of Jason Orendorff
 Sent: 2. april 2008 13:46
 To: Jeff Dyer
 Cc: es4-discuss
 Subject: Re: grammar update
 
 On Sun, Mar 30, 2008 at 7:29 PM, Jeff Dyer [EMAIL PROTECTED] wrote:
   I've updated the ES4 grammar files linked from
http://wiki.ecmascript.org/doku.php?id=proposals:normative_grammar
 
 Thanks for doing this.  I noticed that the grammar doesn't allow this:
 
   [addr
 for each (user in users)
   if (user.isAdministrator)
 for each (addr in user.addresses)]
 
 Is this intentional?  Both Python and Haskell allow the 
 analogous listcomp.  (Oddly enough, if you anti-optimize 
 this, moving the IfCondition to be after the last 
 ForInExpression, the proposed ES4 grammar accepts that.)
 
 Separately, I would appreciate let clauses in ArrayComprehensions:
 
   [[trial, phi]
 for each (trial in trials)
   let (phi = hugeExpensiveCalculation(trial))
 if (phi  1000)]
 
 Haskell has this feature.  I occasionally reach for it in 
 Python and it isn't there.
 
 -j
 ___
 Es4-discuss mailing list
 Es4-discuss@mozilla.org
 https://mail.mozilla.org/listinfo/es4-discuss
 
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

RE: Strict mode recap

2008-04-02 Thread Lars Hansen 
 -Original Message-
 From: [EMAIL PROTECTED] 
 [mailto:[EMAIL PROTECTED] On Behalf Of Lars Hansen
 Sent: 31. mars 2008 20:09
 To: Waldemar Horwat; es4-discuss@mozilla.org
 Subject: RE: Strict mode recap
 
  -Original Message-
  From: [EMAIL PROTECTED] 
  [mailto:[EMAIL PROTECTED] On Behalf Of 
 Waldemar Horwat
  Sent: 31. mars 2008 18:03
  To: es4-discuss@mozilla.org
  Subject: Strict mode recap
  
  - delete o.x when x is not in o but in the proto will throw
 
 Actually delete o.x when x is not an own property on o, 
 regardless of whether x in o.

And since destructuring is just sugar for property references, 
this implies that destructuring that attempts to access fields
not present will fail too, which is another thing that came
up in a (possibly private) discussion around strict mode.

--lars
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

RE: let* is the new var

2008-04-02 Thread Lars Hansen 
Don't remember this ever coming up; I always assumed it would be like 
for ES3 code (scopes of names are the entire block; functions are
initialized first; then variables in order).

--lars 

 -Original Message-
 From: [EMAIL PROTECTED] 
 [mailto:[EMAIL PROTECTED] On Behalf Of P T Withington
 Sent: 26. mars 2008 05:48
 To: Dave Herman
 Cc: es4-discuss Discuss; Jon Zeppieri
 Subject: Re: let* is the new var
 
 This conversation makes me ask, what is the semantics of var 
 in a class declaration?  E.g.:
 
 class ... {
function foo ...
var fooAlias = foo;
 
var bar = 42;
var bletch = bar + 1;
 
 etc.
 
 Same rules?  All slots created at the top of the block and 
 initializations executed in order?  I'm particularly 
 interested in the case of creating an alias to a function.
 
 On 2008-03-25, at 19:03 EDT, Dave Herman wrote:
  Created as ticket #375:
 
  http://bugs.ecmascript.org/ticket/375
 
  Dave
 
  ___
  Es4-discuss mailing list
  Es4-discuss@mozilla.org
  https://mail.mozilla.org/listinfo/es4-discuss
 
 ___
 Es4-discuss mailing list
 Es4-discuss@mozilla.org
 https://mail.mozilla.org/listinfo/es4-discuss
 
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

RE: let* is the new var

2008-04-02 Thread Jeff Dyer 
Let's use 866 7052554, 6608431. dialing now...

 -Original Message-
 From: [EMAIL PROTECTED] [mailto:es4-discuss-
 [EMAIL PROTECTED] On Behalf Of Lars Hansen
 Sent: Wednesday, April 02, 2008 2:49 PM
 To: P T Withington; Dave Herman
 Cc: es4-discuss Discuss; Jon Zeppieri
 Subject: RE: let* is the new var
 
 Don't remember this ever coming up; I always assumed it would be like
 for ES3 code (scopes of names are the entire block; functions are
 initialized first; then variables in order).
 
 --lars
 
  -Original Message-
  From: [EMAIL PROTECTED]
  [mailto:[EMAIL PROTECTED] On Behalf Of P T Withington
  Sent: 26. mars 2008 05:48
  To: Dave Herman
  Cc: es4-discuss Discuss; Jon Zeppieri
  Subject: Re: let* is the new var
 
  This conversation makes me ask, what is the semantics of var
  in a class declaration?  E.g.:
 
  class ... {
 function foo ...
 var fooAlias = foo;
 
 var bar = 42;
 var bletch = bar + 1;
 
  etc.
 
  Same rules?  All slots created at the top of the block and
  initializations executed in order?  I'm particularly
  interested in the case of creating an alias to a function.
 
  On 2008-03-25, at 19:03 EDT, Dave Herman wrote:
   Created as ticket #375:
  
   http://bugs.ecmascript.org/ticket/375
  
   Dave
  
   ___
   Es4-discuss mailing list
   Es4-discuss@mozilla.org
   https://mail.mozilla.org/listinfo/es4-discuss
 
  ___
  Es4-discuss mailing list
  Es4-discuss@mozilla.org
  https://mail.mozilla.org/listinfo/es4-discuss
 
 ___
 Es4-discuss mailing list
 Es4-discuss@mozilla.org
 https://mail.mozilla.org/listinfo/es4-discuss
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

RE: let* is the new var

2008-04-02 Thread Jeff Dyer 
Oops. Never mind :)

Jd

 -Original Message-
 From: [EMAIL PROTECTED] [mailto:es4-discuss-
 [EMAIL PROTECTED] On Behalf Of Jeff Dyer
 Sent: Wednesday, April 02, 2008 3:06 PM
 To: Lars Hansen; P T Withington; Dave Herman
 Cc: es4-discuss Discuss; Jon Zeppieri
 Subject: RE: let* is the new var
 
 Let's use 866 7052554, 6608431. dialing now...
 
  -Original Message-
  From: [EMAIL PROTECTED] [mailto:es4-discuss-
  [EMAIL PROTECTED] On Behalf Of Lars Hansen
  Sent: Wednesday, April 02, 2008 2:49 PM
  To: P T Withington; Dave Herman
  Cc: es4-discuss Discuss; Jon Zeppieri
  Subject: RE: let* is the new var
 
  Don't remember this ever coming up; I always assumed it would be
like
  for ES3 code (scopes of names are the entire block; functions are
  initialized first; then variables in order).
 
  --lars
 
   -Original Message-
   From: [EMAIL PROTECTED]
   [mailto:[EMAIL PROTECTED] On Behalf Of P T
Withington
   Sent: 26. mars 2008 05:48
   To: Dave Herman
   Cc: es4-discuss Discuss; Jon Zeppieri
   Subject: Re: let* is the new var
  
   This conversation makes me ask, what is the semantics of var
   in a class declaration?  E.g.:
  
   class ... {
  function foo ...
  var fooAlias = foo;
  
  var bar = 42;
  var bletch = bar + 1;
  
   etc.
  
   Same rules?  All slots created at the top of the block and
   initializations executed in order?  I'm particularly
   interested in the case of creating an alias to a function.
  
   On 2008-03-25, at 19:03 EDT, Dave Herman wrote:
Created as ticket #375:
   
http://bugs.ecmascript.org/ticket/375
   
Dave
   
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
  
   ___
   Es4-discuss mailing list
   Es4-discuss@mozilla.org
   https://mail.mozilla.org/listinfo/es4-discuss
  
  ___
  Es4-discuss mailing list
  Es4-discuss@mozilla.org
  https://mail.mozilla.org/listinfo/es4-discuss
 ___
 Es4-discuss mailing list
 Es4-discuss@mozilla.org
 https://mail.mozilla.org/listinfo/es4-discuss
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: let* is the new var

2008-04-02 Thread Michael O'Brien 
We define the slots for vars and functions first at the top of the block
and do initializations in-order where they reside in the code flow. So:

class XX {
function foo ...

//  fooAlias exists here but is undefined
var fooAlias = foo

//  fooAlias is now initialized
}


Michael


On Apr 2, 2008, at 2:49 PM, Lars Hansen wrote:
 Don't remember this ever coming up; I always assumed it would be like
 for ES3 code (scopes of names are the entire block; functions are
 initialized first; then variables in order).

 --lars

 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED] On Behalf Of P T Withington
 Sent: 26. mars 2008 05:48
 To: Dave Herman
 Cc: es4-discuss Discuss; Jon Zeppieri
 Subject: Re: let* is the new var

 This conversation makes me ask, what is the semantics of var
 in a class declaration?  E.g.:

 class ... {
   function foo ...
   var fooAlias = foo;

   var bar = 42;
   var bletch = bar + 1;

 etc.

 Same rules?  All slots created at the top of the block and
 initializations executed in order?  I'm particularly
 interested in the case of creating an alias to a function.

 On 2008-03-25, at 19:03 EDT, Dave Herman wrote:
 Created as ticket #375:

 http://bugs.ecmascript.org/ticket/375

 Dave

 ___
 Es4-discuss mailing list
 Es4-discuss@mozilla.org
 https://mail.mozilla.org/listinfo/es4-discuss

 ___
 Es4-discuss mailing list
 Es4-discuss@mozilla.org
 https://mail.mozilla.org/listinfo/es4-discuss

 ___
 Es4-discuss mailing list
 Es4-discuss@mozilla.org
 https://mail.mozilla.org/listinfo/es4-discuss

___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: grammar update

2008-04-02 Thread Brendan Eich 
On Apr 2, 2008, at 1:03 PM, Lars Hansen wrote:

 Looks like those restrictions (condition only at the end, only 'for',
 'for each',
 and 'if' clauses) originate in Brendan's original (too-sketchy)
 proposal, see
 the Comprehensions section of this page:

 http://wiki.ecmascript.org/doku.php? 
 id=proposals:iterators_and_generator
 s

This is my fault -- I went by the examples in

http://www.python.org/dev/peps/pep-0202/

and did not include the full grammar from

http://www.python.org/doc/current/ref/lists.html#l2h-238

cited therein -- apologies to all and thanks to Jason for pointing  
this out.

 IMO we're looking for simple and useful comprehensions for ES4.  I
 think extensions like the ones you are suggesting, though clearly
 useful,
 should be prototyped elsewhere before going into the language spec, or
 at a minimum, be presented in a better developed proposal.

This is all thin syntactic sugar, so I don't agree it rocks the boat  
too much to follow the full prototype in Python. I'll update the  
proposal, since it claims to follow the PEP, but fails since the PEP  
cites the RM.

Jason wrote:

 Separately, I would appreciate let clauses in ArrayComprehensions:

   [[trial, phi]
 for each (trial in trials)
   let (phi = hugeExpensiveCalculation(trial))
 if (phi  1000)]

 Haskell has this feature.  I occasionally reach for it in
 Python and it isn't there.

Lars, you didn't cite this use-case for let statements, aka let  
blocks :-P. Firefox 2 and 3 (JS1.7 and 1.8) have support for let  
blocks, but again not embedded in comprehensions. As Jason notes,  
Python didn't follow Haskell here (if that was the order of  
evolution). I don't propose we do this for ES4, since let blocks are  
out according to all who've opined on the spreadsheet.

/be

___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: Strict mode recap

2008-04-02 Thread Jon Zeppieri 
On 3/31/08, Lars Hansen [EMAIL PROTECTED] wrote:

 Having thought more about this, we may get away with less
  draconian measures for lexically scoped eval -- it's enough
  to simply decree that eval may not add bindings to the
  caller's binding object in strict mode (a simple run-time check,
  effectively the same as disabling global variable auto-creation).

  The observation is that reference forms like expr::[expr] require
  the same functionality as the constrained, lexically scoped eval
  would require anyway, so the benefit of outlawing eval except for
  matters of taste is doubtful both in terms of implementation cost
  and simplified semantics.

Lars, does this mean that expr::[expr] can't introduce lexical
bindings?  Or:  in strict mode, it can't, but in standard it can?
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

RE: Strict mode recap

2008-04-02 Thread Lars Hansen 
 -Original Message-
 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On 
 Behalf Of Jon Zeppieri
 Sent: 2. april 2008 17:51
 To: Lars Hansen
 Cc: Waldemar Horwat; es4-discuss@mozilla.org
 Subject: Re: Strict mode recap
 
 On 3/31/08, Lars Hansen [EMAIL PROTECTED] wrote:
 
  Having thought more about this, we may get away with less draconian 
  measures for lexically scoped eval -- it's enough  to simply decree 
  that eval may not add bindings to the  caller's binding object in 
  strict mode (a simple run-time check,  effectively the same as 
  disabling global variable auto-creation).
 
   The observation is that reference forms like expr::[expr] require  
  the same functionality as the constrained, lexically scoped eval  
  would require anyway, so the benefit of outlawing eval except for  
  matters of taste is doubtful both in terms of implementation cost
and 
  simplified semantics.
 
 Lars, does this mean that expr::[expr] can't introduce 
 lexical bindings?  Or:  in strict mode, it can't, but in 
 standard it can?

It can't introduce bindings; it's just a name.

--lars
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

RE: grammar update

2008-04-02 Thread Lars Hansen 
 -Original Message-
 From: Brendan Eich [mailto:[EMAIL PROTECTED] 
 Sent: 2. april 2008 17:15
 To: Lars Hansen
 Cc: Jason Orendorff; Jeff Dyer; es4-discuss
 Subject: Re: grammar update
 
 On Apr 2, 2008, at 1:03 PM, Lars Hansen wrote:
 
  Looks like those restrictions (condition only at the end, 
 only 'for', 
  'for each', and 'if' clauses) originate in Brendan's original 
  (too-sketchy) proposal, see the Comprehensions section of 
 this page:
 
  http://wiki.ecmascript.org/doku.php? 
  id=proposals:iterators_and_generator
  s
 
 This is my fault -- I went by the examples in
 
 http://www.python.org/dev/peps/pep-0202/
 
 and did not include the full grammar from
 
 http://www.python.org/doc/current/ref/lists.html#l2h-238
 
 cited therein -- apologies to all and thanks to Jason for 
 pointing this out.
 
  IMO we're looking for simple and useful comprehensions for ES4.  I 
  think extensions like the ones you are suggesting, though clearly 
  useful, should be prototyped elsewhere before going into 
 the language 
  spec, or at a minimum, be presented in a better developed proposal.
 
 This is all thin syntactic sugar, so I don't agree it rocks 
 the boat too much to follow the full prototype in Python. 
 I'll update the proposal, since it claims to follow the PEP, 
 but fails since the PEP cites the RM.

The PEP is scarcely relevant; what we need are comprehensive
proposals for ES4.

 Jason wrote:
 
  Separately, I would appreciate let clauses in ArrayComprehensions:
 
[[trial, phi]
  for each (trial in trials)
let (phi = hugeExpensiveCalculation(trial))
  if (phi  1000)]
 
  Haskell has this feature.  I occasionally reach for it in 
 Python and 
  it isn't there.
 
 Lars, you didn't cite this use-case for let statements, aka 
 let blocks :-P. Firefox 2 and 3 (JS1.7 and 1.8) have support 
 for let blocks, but again not embedded in comprehensions. As 
 Jason notes, Python didn't follow Haskell here (if that was 
 the order of evolution). I don't propose we do this for ES4, 
 since let blocks are out according to all who've opined on 
 the spreadsheet.

The syntax Jason uses is not for let blocks, but for let 
expressions.  Not that I see how it matters, since surely the
'for each' and 'if' forms in array comprehensions are not 
meant to be taken to be the same as their statement counterparts
in all ways.

Please do update the spec for comprehensions; I will not make
it my job to figure out what you meant by studying Python.  The
spec that's there is too informal as well, consisting only of
illustrative examples.  It needs (probably) a grammar and 
semantics at a minimum.

(The page the generator proposal is on is already far too large; 
I suggest that you break generators out as a separate proposal.)

--lars
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: Strict mode recap

2008-04-02 Thread Jon Zeppieri 
On 4/2/08, Lars Hansen [EMAIL PROTECTED] wrote:
  
   Lars, does this mean that expr::[expr] can't introduce
   lexical bindings?  Or:  in strict mode, it can't, but in
   standard it can?


 It can't introduce bindings; it's just a name.

I meant something like:

var foo::[bar] = baz;

My objection to expr::[expr] in earlier messages was based on the
assumption that these computed names could be used on the left-hand
side of an assignment expression -- which, I'm pretty sure, is
syntactically valid.

So, for example:

var foo = hello;
null::[foo] = goodbye;
print(foo); // prints goodbye

But I guess there are two cases: one where a new binding would be
introduced and another where the expression would evaluate to an
already bound name (as in the previous example).

So... are either of those cases legal?
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: grammar update

2008-04-02 Thread Brendan Eich 
On Apr 2, 2008, at 6:01 PM, Lars Hansen wrote:

 This is all thin syntactic sugar, so I don't agree it rocks
 the boat too much to follow the full prototype in Python.
 I'll update the proposal, since it claims to follow the PEP,
 but fails since the PEP cites the RM.

 The PEP is scarcely relevant; what we need are comprehensive
 proposals for ES4.

Touché (again; last time, I won't grovel :-/). My point is that the  
proposal is intended to avoid novelty in comparison to Python,  
especially novelty due to my poor mistake. Not all of ES4 is yet  
fully or even well-specified (e.g., packages -- this was clear from  
the last TC39 meeting). But where use-cases are strong, we are  
persevering, not rejecting over surface-syntax transcription errors,  
or even deeper issues.

 The syntax Jason uses is not for let blocks, but for let
 expressions.

Syntax is secondary to context in making the point that let forms  
containing statements are useful. I'm not quibbling, or trying to  
revive let statements; I am simply citing a use case for the record.

  Not that I see how it matters, since surely the
 'for each' and 'if' forms in array comprehensions are not
 meant to be taken to be the same as their statement counterparts
 in all ways.

They de-sugar internally to statements. The implementation in JS1.7  
transforms the AST in the obvious way before handing it off to the  
code generator. The only new AST node is the one representing the  
consumer of the displayed expression (the expression on the left of  
'for'), which is a built-in form of Array push, as noted in the  
proposal.

These are not anything but statements as far as the programmer can  
tell, but of course the syntax is restricted. I'm happy to fix the  
unintended over-restriction.

 Please do update the spec for comprehensions; I will not make
 it my job to figure out what you meant by studying Python.  The
 spec that's there is too informal as well, consisting only of
 illustrative examples.  It needs (probably) a grammar and
 semantics at a minimum.

Ok.

 (The page the generator proposal is on is already far too large;
 I suggest that you break generators out as a separate proposal.)

Will do.

/be

___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

RE: Strict mode recap

2008-04-02 Thread Lars Hansen 
 -Original Message-
 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On 
 Behalf Of Jon Zeppieri
 Sent: 2. april 2008 19:06
 To: Lars Hansen
 Cc: es4-discuss@mozilla.org
 Subject: Re: Strict mode recap
 
 On 4/2/08, Lars Hansen [EMAIL PROTECTED] wrote:
   
Lars, does this mean that expr::[expr] can't introduce  
  lexical 
  bindings?  Or:  in strict mode, it can't, but in   standard it can?
 
 
  It can't introduce bindings; it's just a name.
 
 I meant something like:
 
 var foo::[bar] = baz;
 
 My objection to expr::[expr] in earlier messages was based on 
 the assumption that these computed names could be used on the 
 left-hand side of an assignment expression -- which, I'm 
 pretty sure, is syntactically valid.

But that by itself can't introduce bindings (except global ones).

 So, for example:
 
 var foo = hello;
 null::[foo] = goodbye;
 print(foo); // prints goodbye
 
 But I guess there are two cases: one where a new binding 
 would be introduced and another where the expression would 
 evaluate to an already bound name (as in the previous example).
 
 So... are either of those cases legal?

If you want to introduce a new binding then you have to do eg

  ns var x = E

to introduce ns::x, and ns has to reference a namespace 
definition, so it's not variable.  Nor is the x, obviously.
But in that case:

  var v1 = ns
  var v2 = x
  v1::[v2] = 20

updates ns::x, AFAIK.  Nothing you can't do with lexically
scoped eval.

--lars
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: Strict mode recap

2008-04-02 Thread Jon Zeppieri 
On 4/2/08, Lars Hansen [EMAIL PROTECTED] wrote:
  
   I meant something like:
  
   var foo::[bar] = baz;
  
   My objection to expr::[expr] in earlier messages was based on
   the assumption that these computed names could be used on the
   left-hand side of an assignment expression -- which, I'm
   pretty sure, is syntactically valid.


 But that by itself can't introduce bindings (except global ones).

I didn't know that, but I'm happy to hear it.  I figured, from the
syntactic form alone, that:

var foo::[bar] = ...

... would introduce a function-local binding (if the name wasn't
already bound) -- since that's what var normally does.


 If you want to introduce a new binding then you have to do eg

   ns var x = E

  to introduce ns::x, and ns has to reference a namespace
  definition, so it's not variable.  Nor is the x, obviously.

Good. But then why allow:

var expr::[expr] = ...

... at all?  (I'm specifically referring to the fact that 'var'
appears before the name.)  This has the syntactic form of a
definition, but it can't actually be one, according to what you've
written.  It could only be an assignment.  (Okay, I guess it could
introduce a property on the global object, but that's already a
special case and doesn't require definition syntax.)

  But in that case:

   var v1 = ns
   var v2 = x
   v1::[v2] = 20

  updates ns::x, AFAIK.  Nothing you can't do with lexically
  scoped eval.

That, by itself, isn't exactly an selling point; no one likes
lexically scoped eval.

I find computed names less objectionable now that I know local
bindings can't be introduced by them.  (I thought that shadowing could
occur, which wouldn't be detectable until runtime.  Of course, that is
true of 'with' -- but, again, hardly a selling point.)  Can't say I'd
be sorry if they were removed from the language, though.

Is this already in AS3?  If so, is it often used?

-Jon




  --lars


___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss