RE: Strict mode recap

[Lars Hansen]

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On 
> Behalf Of Jon Zeppieri
> Sent: 2. april 2008 20:51
> To: Lars Hansen
> Cc: es4-discuss@mozilla.org
> Subject: Re: Strict mode recap
> 
> 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.

That form is not allowed, to my knowledge.  If the grammar allows it
then this could be (a) a bug or (b) missing semantic constraints.

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

It's not.

> (I'm specifically referring to the fact that 'var'
> appears before the name.)

I understand that.

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

It should be illegal.

> >  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 would say that "almost no one likes lexically scoped eval, almost 
all of the time". :)  And the main reasons to dislike it are that
it can introduce bindings and that it is invisible (if implemented
like in Firefox, which is not required by ES3).

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

The syntax comes from E4X, which is incorporated into AS3 and
Spidermonkey.  Try this in Firefox:

  
  var x = http://www.opera.com/";>Hi
there
  var ns = new Namespace("http://www.opera.com/";);
  var em = "q"
  document.writeln(x.ns::[em]);
  

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

Re: Strict mode recap

[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

Re: grammar update

[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

[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

[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

[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

[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: Strict mode recap

[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: grammar update

[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: let* is the new var

[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: let* is the new var

[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

[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

[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: Strict mode recap

[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: grammar update

[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: grammar update

[Jason Orendorff]

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