Re: eval of let, etc. Was: Re: restrictions on let declarations

[Allen Wirfs-Brock]

Right, let/const/class

Allen

On Feb 17, 2014, at 2:19 PM, Mark Miller wrote:

> No, absolutely not. By "lexical", I took Allen to mean the new reliably 
> block-local binding forms: "let", "const", "class"
> 
> 
> On Mon, Feb 17, 2014 at 2:17 PM, Erik Arvidsson  
> wrote:
> I'm getting vary. Does that mean that you want to change the semantics since 
> ES5.1?
> 
> 
> On Mon Feb 17 2014 at 5:12:24 PM, Mark S. Miller  wrote:
> +1.
> 
> 
> On Mon, Feb 17, 2014 at 2:06 PM, Allen Wirfs-Brock  
> wrote:
> See 
> http://people.mozilla.org/~jorendorff/es6-draft.html#sec-delete-operator-runtime-semantics-evaluation
>  
> 
> A better statement of the question would be can we agree that lexical 
> bindings created by eval are always non-deletable binding.  Where or not is 
> throws which the various modes is already determined by the existing spec. 
> for delete based upon whether or not the binding is deletable.
> 
> Allen
> 
> 
> 
> 
> On Feb 17, 2014, at 1:16 PM, Mark S. Miller wrote:
> 
>> In this context, there are two things you might mean by "throws":
>> a) That this delete is an early error within the evaled program, and 
>> therefore throws before any of the code in the evaled program executes.
>> b) That the delete is a dynamic error that happens when the delete executes, 
>> and therefore that the evaled code prior to the delete has executed before 
>> the error is thrown.
>> 
>> -1 on #b.
>> 
>> Assuming you mean #a, between #a and silence, I'm torn. Here are pros and 
>> cons:
>> pro #a: The program is wrong. Silence fails to bring it to anyone's 
>> attention, making the mistake less likely to be fixed. And making it more 
>> likely the program's execution deviates from author's intent.
>> con #a: Silence on sloppy wrong programs are least surprise, and is arguably 
>> the most vivid different between sloppy and strict.
>> 
>> I doubt there's any sensible choices other than #a and silence.
>> 
>> 
>> 
>> On Mon, Feb 17, 2014 at 12:52 PM, Allen Wirfs-Brock  
>> wrote:
>> So, #3 appears to be the winner.
>> 
>> Given that,  can we also agree that  this is throws (or at least that the 
>> delete does nothing):
>> 
>> eval ("let x=5; delete x;");
>> 
>> (bug https://bugs.ecmascript.org/show_bug.cgi?id= )
>> 
>> Allen
>> 
>> 
>> 
>> On Feb 17, 2014, at 8:02 AM, Erik Arvidsson wrote:
>> 
>>> I'm also fine with 3. 
>>> 
>>> On Mon Feb 17 2014 at 10:39:47 AM, Jeremy Martin  wrote:
>>> Happy to concede to #3 on my end.  Just wanted to be clear that it seems to 
>>> be optimizing for future happiness vs. least surprising behavior (which 
>>> isn't a bad thing).
>>> 
>>> 
>>> On Mon, Feb 17, 2014 at 10:26 AM, Jorge Chamorro  
>>> wrote:
>>> On 17/02/2014, at 13:42, Andreas Rossberg wrote:
>>> > On 15 February 2014 06:10, Brendan Eich  wrote:
>>> >> Allen Wirfs-Brock wrote:
>>> >>>
>>> >>> Another consideration in the back of my mind is that there may be useful
>>> >>> to implementors to knowing that let/const/class declaration are never
>>> >>> dynamically added to a non-global environment.
>>> >>
>>> >> +lots, this should be front of mind.
>>> >>
>>> >> In a block, we want the bindings local to that block to be statically
>>> >> analyzable. We want no non-local mode effects. So, #3 still wins.
>>> >
>>> > Strongly seconded.
>>> 
>>> And even thirded.
>>> 
>>> --
>>> ( Jorge )();
>>> ___
>>> es-discuss mailing list
>>> es-discuss@mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>> 
>>> 
>>> 
>>> -- 
>>> Jeremy Martin
>>> 661.312.3853
>>> http://devsmash.com
>>> @jmar777
>>> ___
>>> 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
>> 
>> 
>> 
>> 
>> -- 
>> Cheers,
>> --MarkM
> 
> 
> 
> 
> -- 
> Cheers,
> --MarkM
> 
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
> 
> 
> 
> 
> -- 
> 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: eval of let, etc. Was: Re: restrictions on let declarations

[Mark Miller]

No, absolutely not. By "lexical", I took Allen to mean the new reliably
block-local binding forms: "let", "const", "class"


On Mon, Feb 17, 2014 at 2:17 PM, Erik Arvidsson wrote:

> I'm getting vary. Does that mean that you want to change the semantics
> since ES5.1?
>
>
> On Mon Feb 17 2014 at 5:12:24 PM, Mark S. Miller 
> wrote:
>
>> +1.
>>
>>
>> On Mon, Feb 17, 2014 at 2:06 PM, Allen Wirfs-Brock > > wrote:
>>
>> See
>> http://people.mozilla.org/~jorendorff/es6-draft.html#sec-delete-operator-runtime-semantics-evaluation
>>
>>
>> A better statement of the question would be can we agree that lexical
>> bindings created by eval are always non-deletable binding.  Where or not is
>> throws which the various modes is already determined by the existing spec.
>> for delete based upon whether or not the binding is deletable.
>>
>> Allen
>>
>>
>>
>>
>> On Feb 17, 2014, at 1:16 PM, Mark S. Miller wrote:
>>
>> In this context, there are two things you might mean by "throws":
>> a) That this delete is an early error within the evaled program, and
>> therefore throws before any of the code in the evaled program executes.
>> b) That the delete is a dynamic error that happens when the delete
>> executes, and therefore that the evaled code prior to the delete has
>> executed before the error is thrown.
>>
>> -1 on #b.
>>
>> Assuming you mean #a, between #a and silence, I'm torn. Here are pros and
>> cons:
>> pro #a: The program is wrong. Silence fails to bring it to anyone's
>> attention, making the mistake less likely to be fixed. And making it more
>> likely the program's execution deviates from author's intent.
>> con #a: Silence on sloppy wrong programs are least surprise, and is
>> arguably the most vivid different between sloppy and strict.
>>
>> I doubt there's any sensible choices other than #a and silence.
>>
>>
>>
>> On Mon, Feb 17, 2014 at 12:52 PM, Allen Wirfs-Brock <
>> al...@wirfs-brock.com> wrote:
>>
>> So, #3 appears to be the winner.
>>
>> Given that,  can we also agree that  this is throws (or at least that the
>> delete does nothing):
>>
>> eval ("let x=5; delete x;");
>>
>> (bug https://bugs.ecmascript.org/show_bug.cgi?id= )
>>
>> Allen
>>
>>
>>
>> On Feb 17, 2014, at 8:02 AM, Erik Arvidsson wrote:
>>
>> I'm also fine with 3.
>>
>> On Mon Feb 17 2014 at 10:39:47 AM, Jeremy Martin 
>> wrote:
>>
>> Happy to concede to #3 on my end.  Just wanted to be clear that it seems
>> to be optimizing for future happiness vs. least surprising behavior (which
>> isn't a bad thing).
>>
>>
>> On Mon, Feb 17, 2014 at 10:26 AM, Jorge Chamorro > > wrote:
>>
>>  On 17/02/2014, at 13:42, Andreas Rossberg wrote:
>> > On 15 February 2014 06:10, Brendan Eich  wrote:
>> >> Allen Wirfs-Brock wrote:
>> >>>
>> >>> Another consideration in the back of my mind is that there may be
>> useful
>> >>> to implementors to knowing that let/const/class declaration are never
>> >>> dynamically added to a non-global environment.
>> >>
>> >> +lots, this should be front of mind.
>> >>
>> >> In a block, we want the bindings local to that block to be statically
>> >> analyzable. We want no non-local mode effects. So, #3 still wins.
>> >
>> > Strongly seconded.
>>
>> And even thirded.
>>
>> --
>> ( Jorge )();
>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>>
>>
>> --
>> Jeremy Martin
>> 661.312.3853
>> http://devsmash.com
>> @jmar777
>>
>> ___
>> 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
>>
>>
>>
>>
>> --
>> Cheers,
>> --MarkM
>>
>>
>>
>>
>>
>> --
>> Cheers,
>> --MarkM
>>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>


-- 
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: eval of let, etc. Was: Re: restrictions on let declarations

[Erik Arvidsson]

I'm getting vary. Does that mean that you want to change the semantics
since ES5.1?

On Mon Feb 17 2014 at 5:12:24 PM, Mark S. Miller  wrote:

> +1.
>
>
> On Mon, Feb 17, 2014 at 2:06 PM, Allen Wirfs-Brock 
> wrote:
>
> See
> http://people.mozilla.org/~jorendorff/es6-draft.html#sec-delete-operator-runtime-semantics-evaluation
>
>
> A better statement of the question would be can we agree that lexical
> bindings created by eval are always non-deletable binding.  Where or not is
> throws which the various modes is already determined by the existing spec.
> for delete based upon whether or not the binding is deletable.
>
> Allen
>
>
>
>
> On Feb 17, 2014, at 1:16 PM, Mark S. Miller wrote:
>
> In this context, there are two things you might mean by "throws":
> a) That this delete is an early error within the evaled program, and
> therefore throws before any of the code in the evaled program executes.
> b) That the delete is a dynamic error that happens when the delete
> executes, and therefore that the evaled code prior to the delete has
> executed before the error is thrown.
>
> -1 on #b.
>
> Assuming you mean #a, between #a and silence, I'm torn. Here are pros and
> cons:
> pro #a: The program is wrong. Silence fails to bring it to anyone's
> attention, making the mistake less likely to be fixed. And making it more
> likely the program's execution deviates from author's intent.
> con #a: Silence on sloppy wrong programs are least surprise, and is
> arguably the most vivid different between sloppy and strict.
>
> I doubt there's any sensible choices other than #a and silence.
>
>
>
> On Mon, Feb 17, 2014 at 12:52 PM, Allen Wirfs-Brock  > wrote:
>
> So, #3 appears to be the winner.
>
> Given that,  can we also agree that  this is throws (or at least that the
> delete does nothing):
>
> eval ("let x=5; delete x;");
>
> (bug https://bugs.ecmascript.org/show_bug.cgi?id= )
>
> Allen
>
>
>
> On Feb 17, 2014, at 8:02 AM, Erik Arvidsson wrote:
>
> I'm also fine with 3.
>
> On Mon Feb 17 2014 at 10:39:47 AM, Jeremy Martin 
> wrote:
>
> Happy to concede to #3 on my end.  Just wanted to be clear that it seems
> to be optimizing for future happiness vs. least surprising behavior (which
> isn't a bad thing).
>
>
> On Mon, Feb 17, 2014 at 10:26 AM, Jorge Chamorro 
> wrote:
>
>  On 17/02/2014, at 13:42, Andreas Rossberg wrote:
> > On 15 February 2014 06:10, Brendan Eich  wrote:
> >> Allen Wirfs-Brock wrote:
> >>>
> >>> Another consideration in the back of my mind is that there may be
> useful
> >>> to implementors to knowing that let/const/class declaration are never
> >>> dynamically added to a non-global environment.
> >>
> >> +lots, this should be front of mind.
> >>
> >> In a block, we want the bindings local to that block to be statically
> >> analyzable. We want no non-local mode effects. So, #3 still wins.
> >
> > Strongly seconded.
>
> And even thirded.
>
> --
> ( Jorge )();
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
>
>
> --
> Jeremy Martin
> 661.312.3853
> http://devsmash.com
> @jmar777
>
> ___
> 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
>
>
>
>
> --
> Cheers,
> --MarkM
>
>
>
>
>
> --
> Cheers,
> --MarkM
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: eval of let, etc. Was: Re: restrictions on let declarations

[Mark S. Miller]

+1.


On Mon, Feb 17, 2014 at 2:06 PM, Allen Wirfs-Brock wrote:

> See
> http://people.mozilla.org/~jorendorff/es6-draft.html#sec-delete-operator-runtime-semantics-evaluation
>
>
> A better statement of the question would be can we agree that lexical
> bindings created by eval are always non-deletable binding.  Where or not is
> throws which the various modes is already determined by the existing spec.
> for delete based upon whether or not the binding is deletable.
>
> Allen
>
>
>
>
> On Feb 17, 2014, at 1:16 PM, Mark S. Miller wrote:
>
> In this context, there are two things you might mean by "throws":
> a) That this delete is an early error within the evaled program, and
> therefore throws before any of the code in the evaled program executes.
> b) That the delete is a dynamic error that happens when the delete
> executes, and therefore that the evaled code prior to the delete has
> executed before the error is thrown.
>
> -1 on #b.
>
> Assuming you mean #a, between #a and silence, I'm torn. Here are pros and
> cons:
> pro #a: The program is wrong. Silence fails to bring it to anyone's
> attention, making the mistake less likely to be fixed. And making it more
> likely the program's execution deviates from author's intent.
> con #a: Silence on sloppy wrong programs are least surprise, and is
> arguably the most vivid different between sloppy and strict.
>
> I doubt there's any sensible choices other than #a and silence.
>
>
>
> On Mon, Feb 17, 2014 at 12:52 PM, Allen Wirfs-Brock  > wrote:
>
>> So, #3 appears to be the winner.
>>
>> Given that,  can we also agree that  this is throws (or at least that the
>> delete does nothing):
>>
>> eval ("let x=5; delete x;");
>>
>> (bug https://bugs.ecmascript.org/show_bug.cgi?id= )
>>
>> Allen
>>
>>
>>
>> On Feb 17, 2014, at 8:02 AM, Erik Arvidsson wrote:
>>
>> I'm also fine with 3.
>>
>> On Mon Feb 17 2014 at 10:39:47 AM, Jeremy Martin 
>> wrote:
>>
>>> Happy to concede to #3 on my end.  Just wanted to be clear that it seems
>>> to be optimizing for future happiness vs. least surprising behavior (which
>>> isn't a bad thing).
>>>
>>>
>>> On Mon, Feb 17, 2014 at 10:26 AM, Jorge Chamorro <
>>> jo...@jorgechamorro.com> wrote:
>>>
>>>  On 17/02/2014, at 13:42, Andreas Rossberg wrote:
>>> > On 15 February 2014 06:10, Brendan Eich  wrote:
>>> >> Allen Wirfs-Brock wrote:
>>> >>>
>>> >>> Another consideration in the back of my mind is that there may be
>>> useful
>>> >>> to implementors to knowing that let/const/class declaration are never
>>> >>> dynamically added to a non-global environment.
>>> >>
>>> >> +lots, this should be front of mind.
>>> >>
>>> >> In a block, we want the bindings local to that block to be statically
>>> >> analyzable. We want no non-local mode effects. So, #3 still wins.
>>> >
>>> > Strongly seconded.
>>>
>>> And even thirded.
>>>
>>> --
>>> ( Jorge )();
>>>
>>> ___
>>> es-discuss mailing list
>>> es-discuss@mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>>
>>>
>>>
>>> --
>>> Jeremy Martin
>>> 661.312.3853
>>> http://devsmash.com
>>> @jmar777
>>>
>>> ___
>> 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
>>
>>
>
>
> --
> Cheers,
> --MarkM
>
>
>


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

Re: eval of let, etc. Was: Re: restrictions on let declarations

[Allen Wirfs-Brock]

See 
http://people.mozilla.org/~jorendorff/es6-draft.html#sec-delete-operator-runtime-semantics-evaluation
 

A better statement of the question would be can we agree that lexical bindings 
created by eval are always non-deletable binding.  Where or not is throws which 
the various modes is already determined by the existing spec. for delete based 
upon whether or not the binding is deletable.

Allen




On Feb 17, 2014, at 1:16 PM, Mark S. Miller wrote:

> In this context, there are two things you might mean by "throws":
> a) That this delete is an early error within the evaled program, and 
> therefore throws before any of the code in the evaled program executes.
> b) That the delete is a dynamic error that happens when the delete executes, 
> and therefore that the evaled code prior to the delete has executed before 
> the error is thrown.
> 
> -1 on #b.
> 
> Assuming you mean #a, between #a and silence, I'm torn. Here are pros and 
> cons:
> pro #a: The program is wrong. Silence fails to bring it to anyone's 
> attention, making the mistake less likely to be fixed. And making it more 
> likely the program's execution deviates from author's intent.
> con #a: Silence on sloppy wrong programs are least surprise, and is arguably 
> the most vivid different between sloppy and strict.
> 
> I doubt there's any sensible choices other than #a and silence.
> 
> 
> 
> On Mon, Feb 17, 2014 at 12:52 PM, Allen Wirfs-Brock  
> wrote:
> So, #3 appears to be the winner.
> 
> Given that,  can we also agree that  this is throws (or at least that the 
> delete does nothing):
> 
> eval ("let x=5; delete x;");
> 
> (bug https://bugs.ecmascript.org/show_bug.cgi?id= )
> 
> Allen
> 
> 
> 
> On Feb 17, 2014, at 8:02 AM, Erik Arvidsson wrote:
> 
>> I'm also fine with 3. 
>> 
>> On Mon Feb 17 2014 at 10:39:47 AM, Jeremy Martin  wrote:
>> Happy to concede to #3 on my end.  Just wanted to be clear that it seems to 
>> be optimizing for future happiness vs. least surprising behavior (which 
>> isn't a bad thing).
>> 
>> 
>> On Mon, Feb 17, 2014 at 10:26 AM, Jorge Chamorro  
>> wrote:
>> On 17/02/2014, at 13:42, Andreas Rossberg wrote:
>> > On 15 February 2014 06:10, Brendan Eich  wrote:
>> >> Allen Wirfs-Brock wrote:
>> >>>
>> >>> Another consideration in the back of my mind is that there may be useful
>> >>> to implementors to knowing that let/const/class declaration are never
>> >>> dynamically added to a non-global environment.
>> >>
>> >> +lots, this should be front of mind.
>> >>
>> >> In a block, we want the bindings local to that block to be statically
>> >> analyzable. We want no non-local mode effects. So, #3 still wins.
>> >
>> > Strongly seconded.
>> 
>> And even thirded.
>> 
>> --
>> ( Jorge )();
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>> 
>> 
>> 
>> -- 
>> Jeremy Martin
>> 661.312.3853
>> http://devsmash.com
>> @jmar777
>> ___
>> 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
> 
> 
> 
> 
> -- 
> Cheers,
> --MarkM

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

Re: eval of let, etc. Was: Re: restrictions on let declarations

[Mark S. Miller]

In this context, there are two things you might mean by "throws":
a) That this delete is an early error within the evaled program, and
therefore throws before any of the code in the evaled program executes.
b) That the delete is a dynamic error that happens when the delete
executes, and therefore that the evaled code prior to the delete has
executed before the error is thrown.

-1 on #b.

Assuming you mean #a, between #a and silence, I'm torn. Here are pros and
cons:
pro #a: The program is wrong. Silence fails to bring it to anyone's
attention, making the mistake less likely to be fixed. And making it more
likely the program's execution deviates from author's intent.
con #a: Silence on sloppy wrong programs are least surprise, and is
arguably the most vivid different between sloppy and strict.

I doubt there's any sensible choices other than #a and silence.



On Mon, Feb 17, 2014 at 12:52 PM, Allen Wirfs-Brock
wrote:

> So, #3 appears to be the winner.
>
> Given that,  can we also agree that  this is throws (or at least that the
> delete does nothing):
>
> eval ("let x=5; delete x;");
>
> (bug https://bugs.ecmascript.org/show_bug.cgi?id= )
>
> Allen
>
>
>
> On Feb 17, 2014, at 8:02 AM, Erik Arvidsson wrote:
>
> I'm also fine with 3.
>
> On Mon Feb 17 2014 at 10:39:47 AM, Jeremy Martin 
> wrote:
>
>> Happy to concede to #3 on my end.  Just wanted to be clear that it seems
>> to be optimizing for future happiness vs. least surprising behavior (which
>> isn't a bad thing).
>>
>>
>> On Mon, Feb 17, 2014 at 10:26 AM, Jorge Chamorro > > wrote:
>>
>>  On 17/02/2014, at 13:42, Andreas Rossberg wrote:
>> > On 15 February 2014 06:10, Brendan Eich  wrote:
>> >> Allen Wirfs-Brock wrote:
>> >>>
>> >>> Another consideration in the back of my mind is that there may be
>> useful
>> >>> to implementors to knowing that let/const/class declaration are never
>> >>> dynamically added to a non-global environment.
>> >>
>> >> +lots, this should be front of mind.
>> >>
>> >> In a block, we want the bindings local to that block to be statically
>> >> analyzable. We want no non-local mode effects. So, #3 still wins.
>> >
>> > Strongly seconded.
>>
>> And even thirded.
>>
>> --
>> ( Jorge )();
>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>>
>>
>> --
>> Jeremy Martin
>> 661.312.3853
>> http://devsmash.com
>> @jmar777
>>
>> ___
> 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
>
>


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

Re: eval of let, etc. Was: Re: restrictions on let declarations

[Allen Wirfs-Brock]

So, #3 appears to be the winner.

Given that,  can we also agree that  this is throws (or at least that the 
delete does nothing):

eval ("let x=5; delete x;");

(bug https://bugs.ecmascript.org/show_bug.cgi?id= )

Allen



On Feb 17, 2014, at 8:02 AM, Erik Arvidsson wrote:

> I'm also fine with 3. 
> 
> On Mon Feb 17 2014 at 10:39:47 AM, Jeremy Martin  wrote:
> Happy to concede to #3 on my end.  Just wanted to be clear that it seems to 
> be optimizing for future happiness vs. least surprising behavior (which isn't 
> a bad thing).
> 
> 
> On Mon, Feb 17, 2014 at 10:26 AM, Jorge Chamorro  
> wrote:
> On 17/02/2014, at 13:42, Andreas Rossberg wrote:
> > On 15 February 2014 06:10, Brendan Eich  wrote:
> >> Allen Wirfs-Brock wrote:
> >>>
> >>> Another consideration in the back of my mind is that there may be useful
> >>> to implementors to knowing that let/const/class declaration are never
> >>> dynamically added to a non-global environment.
> >>
> >> +lots, this should be front of mind.
> >>
> >> In a block, we want the bindings local to that block to be statically
> >> analyzable. We want no non-local mode effects. So, #3 still wins.
> >
> > Strongly seconded.
> 
> And even thirded.
> 
> --
> ( Jorge )();
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
> 
> 
> 
> -- 
> Jeremy Martin
> 661.312.3853
> http://devsmash.com
> @jmar777
> ___
> 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: eval of let, etc. Was: Re: restrictions on let declarations

[Erik Arvidsson]

I'm also fine with 3.

On Mon Feb 17 2014 at 10:39:47 AM, Jeremy Martin  wrote:

> Happy to concede to #3 on my end.  Just wanted to be clear that it seems
> to be optimizing for future happiness vs. least surprising behavior (which
> isn't a bad thing).
>
>
> On Mon, Feb 17, 2014 at 10:26 AM, Jorge Chamorro 
> wrote:
>
> On 17/02/2014, at 13:42, Andreas Rossberg wrote:
> > On 15 February 2014 06:10, Brendan Eich  wrote:
> >> Allen Wirfs-Brock wrote:
> >>>
> >>> Another consideration in the back of my mind is that there may be
> useful
> >>> to implementors to knowing that let/const/class declaration are never
> >>> dynamically added to a non-global environment.
> >>
> >> +lots, this should be front of mind.
> >>
> >> In a block, we want the bindings local to that block to be statically
> >> analyzable. We want no non-local mode effects. So, #3 still wins.
> >
> > Strongly seconded.
>
> And even thirded.
>
> --
> ( Jorge )();
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
>
>
> --
> Jeremy Martin
> 661.312.3853
> http://devsmash.com
> @jmar777
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: eval of let, etc. Was: Re: restrictions on let declarations

[Jeremy Martin]

Happy to concede to #3 on my end.  Just wanted to be clear that it seems to
be optimizing for future happiness vs. least surprising behavior (which
isn't a bad thing).


On Mon, Feb 17, 2014 at 10:26 AM, Jorge Chamorro wrote:

> On 17/02/2014, at 13:42, Andreas Rossberg wrote:
> > On 15 February 2014 06:10, Brendan Eich  wrote:
> >> Allen Wirfs-Brock wrote:
> >>>
> >>> Another consideration in the back of my mind is that there may be
> useful
> >>> to implementors to knowing that let/const/class declaration are never
> >>> dynamically added to a non-global environment.
> >>
> >> +lots, this should be front of mind.
> >>
> >> In a block, we want the bindings local to that block to be statically
> >> analyzable. We want no non-local mode effects. So, #3 still wins.
> >
> > Strongly seconded.
>
> And even thirded.
>
> --
> ( Jorge )();
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>



-- 
Jeremy Martin
661.312.3853
http://devsmash.com
@jmar777
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: eval of let, etc. Was: Re: restrictions on let declarations

[Jorge Chamorro]

On 17/02/2014, at 13:42, Andreas Rossberg wrote:
> On 15 February 2014 06:10, Brendan Eich  wrote:
>> Allen Wirfs-Brock wrote:
>>> 
>>> Another consideration in the back of my mind is that there may be useful
>>> to implementors to knowing that let/const/class declaration are never
>>> dynamically added to a non-global environment.
>> 
>> +lots, this should be front of mind.
>> 
>> In a block, we want the bindings local to that block to be statically
>> analyzable. We want no non-local mode effects. So, #3 still wins.
> 
> Strongly seconded.

And even thirded.

-- 
( Jorge )();
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: eval of let, etc. Was: Re: restrictions on let declarations

[Andreas Rossberg]

On 15 February 2014 06:10, Brendan Eich  wrote:
> Allen Wirfs-Brock wrote:
>>
>> On Feb 14, 2014, at 11:38 AM, Jeremy Martin wrote:
>>
>>> >  On further reflection, #3 does feel like trying to rewrite the past.
>>> > For better or worse, non-strict mode allows declarations to persist past 
>>> > the
>>> > eval().  And while strict mode provides a license-to-kill on behavior like
>>> > that, I don't really see strong justification for that kind of surprise
>>> > factor for let in non-strict mode.
>>> >  >  If you're not using strict mode AND you're using eval(), the damage
>>> > is arguably already done (or at least the danger already exists).  
>>> > Changing
>>> > the behavior of let in this case feels like removing an arbitrary* 
>>> > foot-gun
>>> > when we're already in the armory, so to speak.
>>> >  >  * Granted it's not completely arbitrary, since `let` is new whereas
>>> > `var` is not, but hopefully you get my point.
>>
>>
>> Another consideration in the back of my mind is that there may be useful
>> to implementors to knowing that let/const/class declaration are never
>> dynamically added to a non-global environment.
>
> +lots, this should be front of mind.
>
> In a block, we want the bindings local to that block to be statically
> analyzable. We want no non-local mode effects. So, #3 still wins.

Strongly seconded.

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

Re: eval of let, etc. Was: Re: restrictions on let declarations

[Brendan Eich]

Allen Wirfs-Brock wrote:

On Feb 14, 2014, at 11:38 AM, Jeremy Martin wrote:


>  On further reflection, #3 does feel like trying to rewrite the past.  For 
better or worse, non-strict mode allows declarations to persist past the eval().  
And while strict mode provides a license-to-kill on behavior like that, I don't 
really see strong justification for that kind of surprise factor for let in 
non-strict mode.
>  
>  If you're not using strict mode AND you're using eval(), the damage is arguably already done (or at least the danger already exists).  Changing the behavior of let in this case feels like removing an arbitrary* foot-gun when we're already in the armory, so to speak.
>  
>  * Granted it's not completely arbitrary, since `let` is new whereas `var` is not, but hopefully you get my point.


Another consideration in the back of my mind is that there may be useful to 
implementors to knowing that let/const/class declaration are never dynamically 
added to a non-global environment.


+lots, this should be front of mind.

In a block, we want the bindings local to that block to be statically 
analyzable. We want no non-local mode effects. So, #3 still wins.


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

Re: eval of let, etc. Was: Re: restrictions on let declarations

[Brendan Eich]

Allen Wirfs-Brock wrote:

the various forms of eval are already micro-mode, so I'm not sure if those 
points are very relevant.


No, the various forms of eval do not have non-local effects of the kind 
your #2 did!


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

Re: eval of let, etc. Was: Re: restrictions on let declarations

[Allen Wirfs-Brock]

On Feb 14, 2014, at 11:38 AM, Jeremy Martin wrote:

> On further reflection, #3 does feel like trying to rewrite the past.  For 
> better or worse, non-strict mode allows declarations to persist past the 
> eval().  And while strict mode provides a license-to-kill on behavior like 
> that, I don't really see strong justification for that kind of surprise 
> factor for let in non-strict mode.
> 
> If you're not using strict mode AND you're using eval(), the damage is 
> arguably already done (or at least the danger already exists).  Changing the 
> behavior of let in this case feels like removing an arbitrary* foot-gun when 
> we're already in the armory, so to speak.
> 
> * Granted it's not completely arbitrary, since `let` is new whereas `var` is 
> not, but hopefully you get my point.

Another consideration in the back of my mind is that there may be useful to 
implementors to knowing that let/const/class declaration are never dynamically 
added to a non-global environment. 

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

Re: eval of let, etc. Was: Re: restrictions on let declarations

[Jeremy Martin]

On further reflection, #3 does feel like trying to rewrite the past.  For
better or worse, non-strict mode allows declarations to persist past the
eval().  And while strict mode provides a license-to-kill on behavior like
that, I don't really see strong justification for that kind of surprise
factor for let in non-strict mode.

If you're not using strict mode AND you're using eval(), the damage is
arguably already done (or at least the danger already exists).  Changing
the behavior of let in this case feels like removing an arbitrary* foot-gun
when we're already in the armory, so to speak.

* Granted it's not completely arbitrary, since `let` is new whereas `var`
is not, but hopefully you get my point...


On Fri, Feb 14, 2014 at 2:23 PM, Erik Arvidsson wrote:

> 1 or 3. We have already shot down similiar situations to 2 before. I don't
> think it is worth bringing this up again.
>
> 1 is the least surprise. It is just bad practice, but so is eval and non
> strict mode in the first place.
>
> 3 is fine if you think as if there was a block around the whole thing
> (except for functions in block in non strict mode).
>
> On Fri Feb 14 2014 at 1:42:13 PM, Jeremy Martin  wrote:
>
>> > As far as I can see, your #4 and my #1 are exactly the same.  How do
>> you think they differ?
>>
>> Actually, on a second read, I don't think they are.  I was perhaps more
>> explicit regarding strict mode, but I think the behavior there was already
>> clear enough to everyone. :)
>>
>>
>> On Fri, Feb 14, 2014 at 12:14 PM, Allen Wirfs-Brock <
>> al...@wirfs-brock.com> wrote:
>>
>> As far as I can see, your #4 and my #1 are exactly the same.  How do you
>> think they differ?
>>
>> Allen
>>
>> On Feb 14, 2014, at 8:03 AM, Jeremy Martin wrote:
>>
>> I rather hate to say it, but I would've actually expected:
>>
>> 4) Given that the eval'd string doesn't create anything typically
>> considered a "block", the let binding would survive past the completion of
>> the eval in non-strict mode:
>>
>> (function() {
>>   eval("
>>   var answer=42;
>>   let localToEval = true;
>>");
>>   console.log(answer);  // 42
>>   console.log(localToEval);  // true
>> )();
>>
>> (function() {
>>   "use strict";
>>   eval("
>>   var answer=42;
>>   let localToEval = true;
>>");
>>   console.log(answer);  // ReferenceError: answer is not defined
>>   console.log(localToEval);  // ReferenceError: localToEval is
>> not defined
>> )();
>>
>> I'm not necessarily arguing for that behavior, but weighing in since
>> that's the behavior I would have expected based on existing ES5
>> strict/non-strict/eval and ES6 let semantics...
>>
>>
>> On Fri, Feb 14, 2014 at 10:40 AM, Allen Wirfs-Brock <
>> al...@wirfs-brock.com> wrote:
>>
>>
>> On Feb 14, 2014, at 5:49 AM, André Bargull wrote:
>>
>>  How about this?
>>
>> let x= 0;
>> if (1) eval("let x= 42; alert(x);"); //Is this in its own block?
>> alert(x);
>>
>>
>> `eval()` hasn't yet been updated to work with the new lexical declaration
>> forms, but I hope the example from above will be evaluated in a new block.
>> See https://bugs.ecmascript.org/show_bug.cgi?id=1788 for a related bug
>> report.
>>
>>
>> Goood point and this is something I need to specify in the next couple
>> weeks so let's look at the alternatives.
>>
>> First a quick refresher on ES5 era eval.
>>
>> In ES5, the binding behavior of direct eval differs between strict and
>> non-strict modes.
>>
>> In strict mode, each eval instantiates all declarations in a new
>> environment that is immediately nested within the current
>> LexicalEnvironment. The scoping behavior is essentially the same as if the
>> eval code was the body of an iife that occurred at the same place as the
>> eval call.  Bindings introduced by the eval code disappear after completion
>> of the eval.
>>
>> In non-strict mode, each eval instantiates all declarations in the
>> current VariableEnvironment; that is the most immediately enclosing
>> function or global environment.  Bindings introduced by the eval code
>> remain accessible from that VariableEnvironment after completion of the
>> eval.
>>
>> For example:
>> (function() {
>>   "use strict";
>>   eval("var answer=42");
>>   console.log(answer);  // ReferenceError: answer is not defined
>> })();
>>
>> (function() {
>>   eval("var answer=42");
>>   console.log(answer);  // 42
>> })();
>>
>> For ES6, it makes sense for strict mode evals to behave in this exact
>> same way. Each eval takes place in its own environment and no bindings
>> survive the completion of the eval.
>>
>> For ES6, non-strict evals of code containing only var or function
>> declarations must  have exactly the ES5 behavior  in order to maintain
>> compatibility.  But what about eval code that contains new declaration
>> forms (let/const/class) exclusively or in combination with var/function
>> declarat

Re: eval of let, etc. Was: Re: restrictions on let declarations

[Erik Arvidsson]

1 or 3. We have already shot down similiar situations to 2 before. I don't
think it is worth bringing this up again.

1 is the least surprise. It is just bad practice, but so is eval and non
strict mode in the first place.

3 is fine if you think as if there was a block around the whole thing
(except for functions in block in non strict mode).

On Fri Feb 14 2014 at 1:42:13 PM, Jeremy Martin  wrote:

> > As far as I can see, your #4 and my #1 are exactly the same.  How do
> you think they differ?
>
> Actually, on a second read, I don't think they are.  I was perhaps more
> explicit regarding strict mode, but I think the behavior there was already
> clear enough to everyone. :)
>
>
> On Fri, Feb 14, 2014 at 12:14 PM, Allen Wirfs-Brock  > wrote:
>
> As far as I can see, your #4 and my #1 are exactly the same.  How do you
> think they differ?
>
> Allen
>
> On Feb 14, 2014, at 8:03 AM, Jeremy Martin wrote:
>
> I rather hate to say it, but I would've actually expected:
>
> 4) Given that the eval'd string doesn't create anything typically
> considered a "block", the let binding would survive past the completion of
> the eval in non-strict mode:
>
> (function() {
>   eval("
>   var answer=42;
>   let localToEval = true;
>");
>   console.log(answer);  // 42
>   console.log(localToEval);  // true
> )();
>
> (function() {
>   "use strict";
>   eval("
>   var answer=42;
>   let localToEval = true;
>");
>   console.log(answer);  // ReferenceError: answer is not defined
>   console.log(localToEval);  // ReferenceError: localToEval is not
> defined
> )();
>
> I'm not necessarily arguing for that behavior, but weighing in since
> that's the behavior I would have expected based on existing ES5
> strict/non-strict/eval and ES6 let semantics...
>
>
> On Fri, Feb 14, 2014 at 10:40 AM, Allen Wirfs-Brock  > wrote:
>
>
> On Feb 14, 2014, at 5:49 AM, André Bargull wrote:
>
>  How about this?
>
> let x= 0;
> if (1) eval("let x= 42; alert(x);"); //Is this in its own block?
> alert(x);
>
>
> `eval()` hasn't yet been updated to work with the new lexical declaration
> forms, but I hope the example from above will be evaluated in a new block.
> See https://bugs.ecmascript.org/show_bug.cgi?id=1788 for a related bug
> report.
>
>
> Goood point and this is something I need to specify in the next couple
> weeks so let's look at the alternatives.
>
> First a quick refresher on ES5 era eval.
>
> In ES5, the binding behavior of direct eval differs between strict and
> non-strict modes.
>
> In strict mode, each eval instantiates all declarations in a new
> environment that is immediately nested within the current
> LexicalEnvironment. The scoping behavior is essentially the same as if the
> eval code was the body of an iife that occurred at the same place as the
> eval call.  Bindings introduced by the eval code disappear after completion
> of the eval.
>
> In non-strict mode, each eval instantiates all declarations in the current
> VariableEnvironment; that is the most immediately enclosing function or
> global environment.  Bindings introduced by the eval code remain accessible
> from that VariableEnvironment after completion of the eval.
>
> For example:
> (function() {
>   "use strict";
>   eval("var answer=42");
>   console.log(answer);  // ReferenceError: answer is not defined
> })();
>
> (function() {
>   eval("var answer=42");
>   console.log(answer);  // 42
> })();
>
> For ES6, it makes sense for strict mode evals to behave in this exact same
> way. Each eval takes place in its own environment and no bindings survive
> the completion of the eval.
>
> For ES6, non-strict evals of code containing only var or function
> declarations must  have exactly the ES5 behavior  in order to maintain
> compatibility.  But what about eval code that contains new declaration
> forms (let/const/class) exclusively or in combination with var/function
> declarations? Three possibilities come to mind:
>
> 1) Extend the ES5 semantics to include the new declaration forms.  For
> example:
>
> (function() {
>   eval("let answer=42");
>   console.log(answer);  // 42
> })();
>
> 2) Use the strict mode binding semantics  if the eval code directly
> contains any of the new declaration forms:
>
> (function() {
>   eval("
>   var answer=42;
>   let forceSeprateEnvironment = true;
>");
>   console.log(answer);  // ReferenceError: answer is not defined
> })();
>
> 3) Combination.  use ES5 non-strict binding semantics for var/function
> declarations but place let/const/class bindings into a per eval environment:
>
> (function() {
>   eval("
>   var answer=42;
>   let localToEval = true;
>");
>   console.log(answer);  // 42
>   console.log(localToEval);  // ReferenceError: localToEval is not
> defined
> )();
>
>
> It would certainly 

Re: eval of let, etc. Was: Re: restrictions on let declarations

[Jeremy Martin]

> As far as I can see, your #4 and my #1 are exactly the same.  How do you
think they differ?

Actually, on a second read, I don't think they are.  I was perhaps more
explicit regarding strict mode, but I think the behavior there was already
clear enough to everyone. :)


On Fri, Feb 14, 2014 at 12:14 PM, Allen Wirfs-Brock
wrote:

> As far as I can see, your #4 and my #1 are exactly the same.  How do you
> think they differ?
>
> Allen
>
> On Feb 14, 2014, at 8:03 AM, Jeremy Martin wrote:
>
> I rather hate to say it, but I would've actually expected:
>
> 4) Given that the eval'd string doesn't create anything typically
> considered a "block", the let binding would survive past the completion of
> the eval in non-strict mode:
>
> (function() {
>   eval("
>   var answer=42;
>   let localToEval = true;
>");
>   console.log(answer);  // 42
>   console.log(localToEval);  // true
> )();
>
> (function() {
>   "use strict";
>   eval("
>   var answer=42;
>   let localToEval = true;
>");
>   console.log(answer);  // ReferenceError: answer is not defined
>   console.log(localToEval);  // ReferenceError: localToEval is not
> defined
> )();
>
> I'm not necessarily arguing for that behavior, but weighing in since
> that's the behavior I would have expected based on existing ES5
> strict/non-strict/eval and ES6 let semantics...
>
>
> On Fri, Feb 14, 2014 at 10:40 AM, Allen Wirfs-Brock  > wrote:
>
>>
>> On Feb 14, 2014, at 5:49 AM, André Bargull wrote:
>>
>>  How about this?
>>
>> let x= 0;
>> if (1) eval("let x= 42; alert(x);"); //Is this in its own block?
>> alert(x);
>>
>>
>> `eval()` hasn't yet been updated to work with the new lexical declaration
>> forms, but I hope the example from above will be evaluated in a new block.
>> See https://bugs.ecmascript.org/show_bug.cgi?id=1788 for a related bug
>> report.
>>
>>
>> Goood point and this is something I need to specify in the next couple
>> weeks so let's look at the alternatives.
>>
>> First a quick refresher on ES5 era eval.
>>
>> In ES5, the binding behavior of direct eval differs between strict and
>> non-strict modes.
>>
>> In strict mode, each eval instantiates all declarations in a new
>> environment that is immediately nested within the current
>> LexicalEnvironment. The scoping behavior is essentially the same as if the
>> eval code was the body of an iife that occurred at the same place as the
>> eval call.  Bindings introduced by the eval code disappear after completion
>> of the eval.
>>
>> In non-strict mode, each eval instantiates all declarations in the
>> current VariableEnvironment; that is the most immediately enclosing
>> function or global environment.  Bindings introduced by the eval code
>> remain accessible from that VariableEnvironment after completion of the
>> eval.
>>
>> For example:
>> (function() {
>>   "use strict";
>>   eval("var answer=42");
>>   console.log(answer);  // ReferenceError: answer is not defined
>> })();
>>
>> (function() {
>>   eval("var answer=42");
>>   console.log(answer);  // 42
>> })();
>>
>> For ES6, it makes sense for strict mode evals to behave in this exact
>> same way. Each eval takes place in its own environment and no bindings
>> survive the completion of the eval.
>>
>> For ES6, non-strict evals of code containing only var or function
>> declarations must  have exactly the ES5 behavior  in order to maintain
>> compatibility.  But what about eval code that contains new declaration
>> forms (let/const/class) exclusively or in combination with var/function
>> declarations? Three possibilities come to mind:
>>
>> 1) Extend the ES5 semantics to include the new declaration forms.  For
>> example:
>>
>> (function() {
>>   eval("let answer=42");
>>   console.log(answer);  // 42
>> })();
>>
>> 2) Use the strict mode binding semantics  if the eval code directly
>> contains any of the new declaration forms:
>>
>> (function() {
>>   eval("
>>   var answer=42;
>>   let forceSeprateEnvironment = true;
>>");
>>   console.log(answer);  // ReferenceError: answer is not defined
>> })();
>>
>> 3) Combination.  use ES5 non-strict binding semantics for var/function
>> declarations but place let/const/class bindings into a per eval environment:
>>
>> (function() {
>>   eval("
>>   var answer=42;
>>   let localToEval = true;
>>");
>>   console.log(answer);  // 42
>>   console.log(localToEval);  // ReferenceError: localToEval is not
>> defined
>> )();
>>
>>
>> It would certainly be possible to specify #1, but I don't like it. Other
>> than for the global environment it would be cleaner if the new block
>> scope-able declarations  were never dynamically added to the environment.
>>
>> I think either #2 or #3 is plausible.  #2 is a simpler story but
>> introduces a refactoring hazard. If you have some e

Re: eval of let, etc. Was: Re: restrictions on let declarations

[Allen Wirfs-Brock]

On Feb 14, 2014, at 8:54 AM, Brendan Eich wrote:

> Mark S. Miller wrote:
>> I actually prefer #3. Given only knowledge of ES5 and of the rest of ES6, I 
>> find it least surprising. "var"s hoist out of blocks. In non-strict code, 
>> "function"s leak out of blocks in ways that are hard to explain. I can 
>> understand non-strict direct eval as being block-like, in that "var" and 
>> "function" leak out of them, but all the reliably block-local declarations 
>> stay within the direct eval.
>> 
>> Also, I buy the refactoring issue. It's like the problem with micro-modes: 
>> bizarre and unexpected non-local influences.
> 
> Yes, agree on #3 being best. My recollection from past TC39 meetings and 
> discussion here is that #2 will not fly. We do not want some let buried in a 
> large string to eval to contaminate the whole eval'ed program such that vars 
> in it are confined, where they weren't before.
> 
> Just amplifying your refactoring point, but also noting your 
> micro-mode/non-local comment. This is not going to win consensus.

the various forms of eval are already micro-mode, so I'm not sure if those 
points are very relevant.

But, I agree that #3 is a better fit to sloppy mode (ie less surprising) than 
#2 and avoid more refactoring hazards. 

Unless, I see the see the tide turning in some other direction #3 is what I'll 
put into the spec.

Allen


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

Re: eval of let, etc. Was: Re: restrictions on let declarations

[Allen Wirfs-Brock]

As far as I can see, your #4 and my #1 are exactly the same.  How do you think 
they differ?

Allen

On Feb 14, 2014, at 8:03 AM, Jeremy Martin wrote:

> I rather hate to say it, but I would've actually expected:
> 
> 4) Given that the eval'd string doesn't create anything typically considered 
> a "block", the let binding would survive past the completion of the eval in 
> non-strict mode:
> 
> (function() { 
>   eval("
>   var answer=42;
>   let localToEval = true;
>");
>   console.log(answer);  // 42
>   console.log(localToEval);  // true
> )();
> 
> (function() {
>   "use strict";
>   eval("
>   var answer=42;
>   let localToEval = true;
>");
>   console.log(answer);  // ReferenceError: answer is not defined
>   console.log(localToEval);  // ReferenceError: localToEval is not 
> defined
> )();
> 
> I'm not necessarily arguing for that behavior, but weighing in since that's 
> the behavior I would have expected based on existing ES5 
> strict/non-strict/eval and ES6 let semantics...
> 
> 
> On Fri, Feb 14, 2014 at 10:40 AM, Allen Wirfs-Brock  
> wrote:
> 
> On Feb 14, 2014, at 5:49 AM, André Bargull wrote:
>>> How about this? 
>>> 
>>> let x= 0;
>>> if (1) eval("let x= 42; alert(x);"); //Is this in its own block?
>>> alert(x);
>> 
>> `eval()` hasn't yet been updated to work with the new lexical declaration 
>> forms, but I hope the example from above will be evaluated in a new block. 
>> See https://bugs.ecmascript.org/show_bug.cgi?id=1788 for a related bug 
>> report.
> 
> Goood point and this is something I need to specify in the next couple weeks 
> so let's look at the alternatives.
> 
> First a quick refresher on ES5 era eval.
> 
> In ES5, the binding behavior of direct eval differs between strict and 
> non-strict modes.
> 
> In strict mode, each eval instantiates all declarations in a new environment 
> that is immediately nested within the current LexicalEnvironment. The scoping 
> behavior is essentially the same as if the eval code was the body of an iife 
> that occurred at the same place as the eval call.  Bindings introduced by the 
> eval code disappear after completion of the eval.
> 
> In non-strict mode, each eval instantiates all declarations in the current 
> VariableEnvironment; that is the most immediately enclosing function or 
> global environment.  Bindings introduced by the eval code remain accessible 
> from that VariableEnvironment after completion of the eval.
> 
> For example:
> (function() {
>   "use strict";
>   eval("var answer=42");
>   console.log(answer);  // ReferenceError: answer is not defined
> })();
> 
> (function() { 
>   eval("var answer=42");
>   console.log(answer);  // 42
> })();
> 
> For ES6, it makes sense for strict mode evals to behave in this exact same 
> way. Each eval takes place in its own environment and no bindings survive the 
> completion of the eval.
> 
> For ES6, non-strict evals of code containing only var or function 
> declarations must  have exactly the ES5 behavior  in order to maintain 
> compatibility.  But what about eval code that contains new declaration forms 
> (let/const/class) exclusively or in combination with var/function 
> declarations? Three possibilities come to mind:
> 
> 1) Extend the ES5 semantics to include the new declaration forms.  For 
> example:
> 
> (function() { 
>   eval("let answer=42");
>   console.log(answer);  // 42
> })();
> 
> 2) Use the strict mode binding semantics  if the eval code directly contains 
> any of the new declaration forms:
> 
> (function() { 
>   eval("
>   var answer=42;
>   let forceSeprateEnvironment = true;
>");
>   console.log(answer);  // ReferenceError: answer is not defined
> })();
> 
> 3) Combination.  use ES5 non-strict binding semantics for var/function 
> declarations but place let/const/class bindings into a per eval environment:
> 
> (function() { 
>   eval("
>   var answer=42;
>   let localToEval = true;
>");
>   console.log(answer);  // 42
>   console.log(localToEval);  // ReferenceError: localToEval is not defined
> )();
> 
> 
> It would certainly be possible to specify #1, but I don't like it. Other than 
> for the global environment it would be cleaner if the new block scope-able 
> declarations  were never dynamically added to the environment.
> 
> I think either #2 or #3 is plausible.  #2 is a simpler story but introduces a 
> refactoring hazard. If you have some existing eval code that  defines some 
> "global" functions or variables, then simply adding a let/const/class 
> declaration to the eval code ruins those global declarations. 
> 
> I prefer the simplicity of #2, but I also worry about the WTF impact it might 
> have on evolving existing code.
> 
> Can we get away with #2, or are we going to have to go with

Re: eval of let, etc. Was: Re: restrictions on let declarations

[Mark S. Miller]

On Fri, Feb 14, 2014 at 8:26 AM, John Barton  wrote:

> How about "Keyword 'let' not allowed without 'use strict' or in a module".
> ?
>


I wish. I argued strongly that sloppy mode be maintained only to continue
to serve the purpose of being an ES3 compatibility mode, and that we stop
adding new ES6 language features to it. In particular, that we not add
"let" since we could not even specify that "let" be *simply* a declaration
keyword in sloppy mode. Instead, TC39 decided that "let" in sloppy mode is
sometimes a variable, and sometimes indicates a "let" declaration. This is
long decided and TC39 is not going to revisit the admission of "let" into
sloppy mode.

For this and many other reasons, new code should consider sloppy mode to be
WTF toxic waste, to be avoided under all normal circumstances.
Nevertheless, we still need to settle outstanding questions as
non-toxically as possible, given the toxic waste we've already dumped into
sloppy mode. Hence this thread.



>
>
> On Fri, Feb 14, 2014 at 8:18 AM, Mark S. Miller wrote:
>
>> I agree that this is in some sense the least surprising. But it is so
>> unpleasant that I think we should instead opt for the additional surprise
>> of #3 -- that a direct sloppy eval is block-like, even though there aren't
>> any curlies.
>>
>>
>> On Fri, Feb 14, 2014 at 8:03 AM, Jeremy Martin  wrote:
>>
>>> I rather hate to say it, but I would've actually expected:
>>>
>>> 4) Given that the eval'd string doesn't create anything typically
>>> considered a "block", the let binding would survive past the completion of
>>> the eval in non-strict mode:
>>>
>>> (function() {
>>>   eval("
>>>   var answer=42;
>>>   let localToEval = true;
>>>");
>>>   console.log(answer);  // 42
>>>   console.log(localToEval);  // true
>>> )();
>>>
>>>  (function() {
>>>   "use strict";
>>>   eval("
>>>var answer=42;
>>>   let localToEval = true;
>>>");
>>>   console.log(answer);  // ReferenceError: answer is not defined
>>>   console.log(localToEval);  // ReferenceError: localToEval is
>>> not defined
>>> )();
>>>
>>> I'm not necessarily arguing for that behavior, but weighing in since
>>> that's the behavior I would have expected based on existing ES5
>>> strict/non-strict/eval and ES6 let semantics...
>>>
>>>
>>> On Fri, Feb 14, 2014 at 10:40 AM, Allen Wirfs-Brock <
>>> al...@wirfs-brock.com> wrote:
>>>

 On Feb 14, 2014, at 5:49 AM, André Bargull wrote:

  How about this?

 let x= 0;
 if (1) eval("let x= 42; alert(x);"); //Is this in its own block?
 alert(x);


 `eval()` hasn't yet been updated to work with the new lexical
 declaration forms, but I hope the example from above will be evaluated in a
 new block. See https://bugs.ecmascript.org/show_bug.cgi?id=1788 for a
 related bug report.


 Goood point and this is something I need to specify in the next couple
 weeks so let's look at the alternatives.

 First a quick refresher on ES5 era eval.

 In ES5, the binding behavior of direct eval differs between strict and
 non-strict modes.

 In strict mode, each eval instantiates all declarations in a new
 environment that is immediately nested within the current
 LexicalEnvironment. The scoping behavior is essentially the same as if the
 eval code was the body of an iife that occurred at the same place as the
 eval call.  Bindings introduced by the eval code disappear after completion
 of the eval.

 In non-strict mode, each eval instantiates all declarations in the
 current VariableEnvironment; that is the most immediately enclosing
 function or global environment.  Bindings introduced by the eval code
 remain accessible from that VariableEnvironment after completion of the
 eval.

 For example:
 (function() {
   "use strict";
   eval("var answer=42");
   console.log(answer);  // ReferenceError: answer is not defined
 })();

 (function() {
   eval("var answer=42");
   console.log(answer);  // 42
 })();

 For ES6, it makes sense for strict mode evals to behave in this exact
 same way. Each eval takes place in its own environment and no bindings
 survive the completion of the eval.

 For ES6, non-strict evals of code containing only var or function
 declarations must  have exactly the ES5 behavior  in order to maintain
 compatibility.  But what about eval code that contains new declaration
 forms (let/const/class) exclusively or in combination with var/function
 declarations? Three possibilities come to mind:

 1) Extend the ES5 semantics to include the new declaration forms.  For
 example:

 (function() {
   eval("let answer=42");
   console.log(answer);  // 42
 })()

Re: eval of let, etc. Was: Re: restrictions on let declarations

[Brendan Eich]

Mark S. Miller wrote:
I actually prefer #3. Given only knowledge of ES5 and of the rest of 
ES6, I find it least surprising. "var"s hoist out of blocks. In 
non-strict code, "function"s leak out of blocks in ways that are hard 
to explain. I can understand non-strict direct eval as being 
block-like, in that "var" and "function" leak out of them, but all the 
reliably block-local declarations stay within the direct eval.


Also, I buy the refactoring issue. It's like the problem with 
micro-modes: bizarre and unexpected non-local influences.


Yes, agree on #3 being best. My recollection from past TC39 meetings and 
discussion here is that #2 will not fly. We do not want some let buried 
in a large string to eval to contaminate the whole eval'ed program such 
that vars in it are confined, where they weren't before.


Just amplifying your refactoring point, but also noting your 
micro-mode/non-local comment. This is not going to win consensus.


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

Re: eval of let, etc. Was: Re: restrictions on let declarations

[John Barton]

How about "Keyword 'let' not allowed without 'use strict' or in a module". ?


On Fri, Feb 14, 2014 at 8:18 AM, Mark S. Miller  wrote:

> I agree that this is in some sense the least surprising. But it is so
> unpleasant that I think we should instead opt for the additional surprise
> of #3 -- that a direct sloppy eval is block-like, even though there aren't
> any curlies.
>
>
> On Fri, Feb 14, 2014 at 8:03 AM, Jeremy Martin  wrote:
>
>> I rather hate to say it, but I would've actually expected:
>>
>> 4) Given that the eval'd string doesn't create anything typically
>> considered a "block", the let binding would survive past the completion of
>> the eval in non-strict mode:
>>
>> (function() {
>>   eval("
>>   var answer=42;
>>   let localToEval = true;
>>");
>>   console.log(answer);  // 42
>>   console.log(localToEval);  // true
>> )();
>>
>>  (function() {
>>   "use strict";
>>   eval("
>>var answer=42;
>>   let localToEval = true;
>>");
>>   console.log(answer);  // ReferenceError: answer is not defined
>>   console.log(localToEval);  // ReferenceError: localToEval is
>> not defined
>> )();
>>
>> I'm not necessarily arguing for that behavior, but weighing in since
>> that's the behavior I would have expected based on existing ES5
>> strict/non-strict/eval and ES6 let semantics...
>>
>>
>> On Fri, Feb 14, 2014 at 10:40 AM, Allen Wirfs-Brock <
>> al...@wirfs-brock.com> wrote:
>>
>>>
>>> On Feb 14, 2014, at 5:49 AM, André Bargull wrote:
>>>
>>>  How about this?
>>>
>>> let x= 0;
>>> if (1) eval("let x= 42; alert(x);"); //Is this in its own block?
>>> alert(x);
>>>
>>>
>>> `eval()` hasn't yet been updated to work with the new lexical
>>> declaration forms, but I hope the example from above will be evaluated in a
>>> new block. See https://bugs.ecmascript.org/show_bug.cgi?id=1788 for a
>>> related bug report.
>>>
>>>
>>> Goood point and this is something I need to specify in the next couple
>>> weeks so let's look at the alternatives.
>>>
>>> First a quick refresher on ES5 era eval.
>>>
>>> In ES5, the binding behavior of direct eval differs between strict and
>>> non-strict modes.
>>>
>>> In strict mode, each eval instantiates all declarations in a new
>>> environment that is immediately nested within the current
>>> LexicalEnvironment. The scoping behavior is essentially the same as if the
>>> eval code was the body of an iife that occurred at the same place as the
>>> eval call.  Bindings introduced by the eval code disappear after completion
>>> of the eval.
>>>
>>> In non-strict mode, each eval instantiates all declarations in the
>>> current VariableEnvironment; that is the most immediately enclosing
>>> function or global environment.  Bindings introduced by the eval code
>>> remain accessible from that VariableEnvironment after completion of the
>>> eval.
>>>
>>> For example:
>>> (function() {
>>>   "use strict";
>>>   eval("var answer=42");
>>>   console.log(answer);  // ReferenceError: answer is not defined
>>> })();
>>>
>>> (function() {
>>>   eval("var answer=42");
>>>   console.log(answer);  // 42
>>> })();
>>>
>>> For ES6, it makes sense for strict mode evals to behave in this exact
>>> same way. Each eval takes place in its own environment and no bindings
>>> survive the completion of the eval.
>>>
>>> For ES6, non-strict evals of code containing only var or function
>>> declarations must  have exactly the ES5 behavior  in order to maintain
>>> compatibility.  But what about eval code that contains new declaration
>>> forms (let/const/class) exclusively or in combination with var/function
>>> declarations? Three possibilities come to mind:
>>>
>>> 1) Extend the ES5 semantics to include the new declaration forms.  For
>>> example:
>>>
>>> (function() {
>>>   eval("let answer=42");
>>>   console.log(answer);  // 42
>>> })();
>>>
>>> 2) Use the strict mode binding semantics  if the eval code directly
>>> contains any of the new declaration forms:
>>>
>>> (function() {
>>>   eval("
>>>   var answer=42;
>>>   let forceSeprateEnvironment = true;
>>>");
>>>   console.log(answer);  // ReferenceError: answer is not defined
>>> })();
>>>
>>> 3) Combination.  use ES5 non-strict binding semantics for var/function
>>> declarations but place let/const/class bindings into a per eval environment:
>>>
>>> (function() {
>>>   eval("
>>>   var answer=42;
>>>   let localToEval = true;
>>>");
>>>   console.log(answer);  // 42
>>>   console.log(localToEval);  // ReferenceError: localToEval is not
>>> defined
>>> )();
>>>
>>>
>>> It would certainly be possible to specify #1, but I don't like it. Other
>>> than for the global environment it would be cleaner if the new block
>>> scope-able declarations  were never dynamically added to the environment.
>>>
>>> I think either #2 

Re: eval of let, etc. Was: Re: restrictions on let declarations

[Mark S. Miller]

I agree that this is in some sense the least surprising. But it is so
unpleasant that I think we should instead opt for the additional surprise
of #3 -- that a direct sloppy eval is block-like, even though there aren't
any curlies.


On Fri, Feb 14, 2014 at 8:03 AM, Jeremy Martin  wrote:

> I rather hate to say it, but I would've actually expected:
>
> 4) Given that the eval'd string doesn't create anything typically
> considered a "block", the let binding would survive past the completion of
> the eval in non-strict mode:
>
> (function() {
>   eval("
>   var answer=42;
>   let localToEval = true;
>");
>   console.log(answer);  // 42
>   console.log(localToEval);  // true
> )();
>
> (function() {
>   "use strict";
>   eval("
>   var answer=42;
>   let localToEval = true;
>");
>   console.log(answer);  // ReferenceError: answer is not defined
>   console.log(localToEval);  // ReferenceError: localToEval is not
> defined
> )();
>
> I'm not necessarily arguing for that behavior, but weighing in since
> that's the behavior I would have expected based on existing ES5
> strict/non-strict/eval and ES6 let semantics...
>
>
> On Fri, Feb 14, 2014 at 10:40 AM, Allen Wirfs-Brock  > wrote:
>
>>
>> On Feb 14, 2014, at 5:49 AM, André Bargull wrote:
>>
>>  How about this?
>>
>> let x= 0;
>> if (1) eval("let x= 42; alert(x);"); //Is this in its own block?
>> alert(x);
>>
>>
>> `eval()` hasn't yet been updated to work with the new lexical declaration
>> forms, but I hope the example from above will be evaluated in a new block.
>> See https://bugs.ecmascript.org/show_bug.cgi?id=1788 for a related bug
>> report.
>>
>>
>> Goood point and this is something I need to specify in the next couple
>> weeks so let's look at the alternatives.
>>
>> First a quick refresher on ES5 era eval.
>>
>> In ES5, the binding behavior of direct eval differs between strict and
>> non-strict modes.
>>
>> In strict mode, each eval instantiates all declarations in a new
>> environment that is immediately nested within the current
>> LexicalEnvironment. The scoping behavior is essentially the same as if the
>> eval code was the body of an iife that occurred at the same place as the
>> eval call.  Bindings introduced by the eval code disappear after completion
>> of the eval.
>>
>> In non-strict mode, each eval instantiates all declarations in the
>> current VariableEnvironment; that is the most immediately enclosing
>> function or global environment.  Bindings introduced by the eval code
>> remain accessible from that VariableEnvironment after completion of the
>> eval.
>>
>> For example:
>> (function() {
>>   "use strict";
>>   eval("var answer=42");
>>   console.log(answer);  // ReferenceError: answer is not defined
>> })();
>>
>> (function() {
>>   eval("var answer=42");
>>   console.log(answer);  // 42
>> })();
>>
>> For ES6, it makes sense for strict mode evals to behave in this exact
>> same way. Each eval takes place in its own environment and no bindings
>> survive the completion of the eval.
>>
>> For ES6, non-strict evals of code containing only var or function
>> declarations must  have exactly the ES5 behavior  in order to maintain
>> compatibility.  But what about eval code that contains new declaration
>> forms (let/const/class) exclusively or in combination with var/function
>> declarations? Three possibilities come to mind:
>>
>> 1) Extend the ES5 semantics to include the new declaration forms.  For
>> example:
>>
>> (function() {
>>   eval("let answer=42");
>>   console.log(answer);  // 42
>> })();
>>
>> 2) Use the strict mode binding semantics  if the eval code directly
>> contains any of the new declaration forms:
>>
>> (function() {
>>   eval("
>>   var answer=42;
>>   let forceSeprateEnvironment = true;
>>");
>>   console.log(answer);  // ReferenceError: answer is not defined
>> })();
>>
>> 3) Combination.  use ES5 non-strict binding semantics for var/function
>> declarations but place let/const/class bindings into a per eval environment:
>>
>> (function() {
>>   eval("
>>   var answer=42;
>>   let localToEval = true;
>>");
>>   console.log(answer);  // 42
>>   console.log(localToEval);  // ReferenceError: localToEval is not
>> defined
>> )();
>>
>>
>> It would certainly be possible to specify #1, but I don't like it. Other
>> than for the global environment it would be cleaner if the new block
>> scope-able declarations  were never dynamically added to the environment.
>>
>> I think either #2 or #3 is plausible.  #2 is a simpler story but
>> introduces a refactoring hazard. If you have some existing eval code that
>>  defines some "global" functions or variables, then simply adding a
>> let/const/class declaration to the eval code ruins those global
>> declarations.
>>
>> I prefer the simplici

Re: eval of let, etc. Was: Re: restrictions on let declarations

[Mark S. Miller]

On Fri, Feb 14, 2014 at 7:40 AM, Allen Wirfs-Brock wrote:
[...]

>
> 1) Extend the ES5 semantics to include the new declaration forms.  For
> example:
>
> (function() {
>   eval("let answer=42");
>   console.log(answer);  // 42
> })();
>
> 2) Use the strict mode binding semantics  if the eval code directly
> contains any of the new declaration forms:
>
> (function() {
>   eval("
>   var answer=42;
>   let forceSeprateEnvironment = true;
>");
>   console.log(answer);  // ReferenceError: answer is not defined
> })();
>
> 3) Combination.  use ES5 non-strict binding semantics for var/function
> declarations but place let/const/class bindings into a per eval environment:
>
> (function() {
>   eval("
>   var answer=42;
>   let localToEval = true;
>");
>   console.log(answer);  // 42
>   console.log(localToEval);  // ReferenceError: localToEval is not
> defined
> )();
>
>
> It would certainly be possible to specify #1, but I don't like it. Other
> than for the global environment it would be cleaner if the new block
> scope-able declarations  were never dynamically added to the environment.
>
> I think either #2 or #3 is plausible.  #2 is a simpler story but
> introduces a refactoring hazard. If you have some existing eval code that
>  defines some "global" functions or variables, then simply adding a
> let/const/class declaration to the eval code ruins those global
> declarations.
>
> I prefer the simplicity of #2, but I also worry about the WTF impact it
> might have on evolving existing code.
>
> Can we get away with #2, or are we going to have to go with #3?  Are there
> other alternatives?
>

I actually prefer #3. Given only knowledge of ES5 and of the rest of ES6, I
find it least surprising. "var"s hoist out of blocks. In non-strict code,
"function"s leak out of blocks in ways that are hard to explain. I can
understand non-strict direct eval as being block-like, in that "var" and
"function" leak out of them, but all the reliably block-local declarations
stay within the direct eval.

Also, I buy the refactoring issue. It's like the problem with micro-modes:
bizarre and unexpected non-local influences.


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

Re: eval of let, etc. Was: Re: restrictions on let declarations

[Jeremy Martin]

I rather hate to say it, but I would've actually expected:

4) Given that the eval'd string doesn't create anything typically
considered a "block", the let binding would survive past the completion of
the eval in non-strict mode:

(function() {
  eval("
  var answer=42;
  let localToEval = true;
   ");
  console.log(answer);  // 42
  console.log(localToEval);  // true
)();

(function() {
  "use strict";
  eval("
  var answer=42;
  let localToEval = true;
   ");
  console.log(answer);  // ReferenceError: answer is not defined
  console.log(localToEval);  // ReferenceError: localToEval is not
defined
)();

I'm not necessarily arguing for that behavior, but weighing in since that's
the behavior I would have expected based on existing ES5
strict/non-strict/eval and ES6 let semantics...


On Fri, Feb 14, 2014 at 10:40 AM, Allen Wirfs-Brock
wrote:

>
> On Feb 14, 2014, at 5:49 AM, André Bargull wrote:
>
>  How about this?
>
> let x= 0;
> if (1) eval("let x= 42; alert(x);"); //Is this in its own block?
> alert(x);
>
>
> `eval()` hasn't yet been updated to work with the new lexical declaration
> forms, but I hope the example from above will be evaluated in a new block.
> See https://bugs.ecmascript.org/show_bug.cgi?id=1788 for a related bug
> report.
>
>
> Goood point and this is something I need to specify in the next couple
> weeks so let's look at the alternatives.
>
> First a quick refresher on ES5 era eval.
>
> In ES5, the binding behavior of direct eval differs between strict and
> non-strict modes.
>
> In strict mode, each eval instantiates all declarations in a new
> environment that is immediately nested within the current
> LexicalEnvironment. The scoping behavior is essentially the same as if the
> eval code was the body of an iife that occurred at the same place as the
> eval call.  Bindings introduced by the eval code disappear after completion
> of the eval.
>
> In non-strict mode, each eval instantiates all declarations in the current
> VariableEnvironment; that is the most immediately enclosing function or
> global environment.  Bindings introduced by the eval code remain accessible
> from that VariableEnvironment after completion of the eval.
>
> For example:
> (function() {
>   "use strict";
>   eval("var answer=42");
>   console.log(answer);  // ReferenceError: answer is not defined
> })();
>
> (function() {
>   eval("var answer=42");
>   console.log(answer);  // 42
> })();
>
> For ES6, it makes sense for strict mode evals to behave in this exact same
> way. Each eval takes place in its own environment and no bindings survive
> the completion of the eval.
>
> For ES6, non-strict evals of code containing only var or function
> declarations must  have exactly the ES5 behavior  in order to maintain
> compatibility.  But what about eval code that contains new declaration
> forms (let/const/class) exclusively or in combination with var/function
> declarations? Three possibilities come to mind:
>
> 1) Extend the ES5 semantics to include the new declaration forms.  For
> example:
>
> (function() {
>   eval("let answer=42");
>   console.log(answer);  // 42
> })();
>
> 2) Use the strict mode binding semantics  if the eval code directly
> contains any of the new declaration forms:
>
> (function() {
>   eval("
>   var answer=42;
>   let forceSeprateEnvironment = true;
>");
>   console.log(answer);  // ReferenceError: answer is not defined
> })();
>
> 3) Combination.  use ES5 non-strict binding semantics for var/function
> declarations but place let/const/class bindings into a per eval environment:
>
> (function() {
>   eval("
>   var answer=42;
>   let localToEval = true;
>");
>   console.log(answer);  // 42
>   console.log(localToEval);  // ReferenceError: localToEval is not
> defined
> )();
>
>
> It would certainly be possible to specify #1, but I don't like it. Other
> than for the global environment it would be cleaner if the new block
> scope-able declarations  were never dynamically added to the environment.
>
> I think either #2 or #3 is plausible.  #2 is a simpler story but
> introduces a refactoring hazard. If you have some existing eval code that
>  defines some "global" functions or variables, then simply adding a
> let/const/class declaration to the eval code ruins those global
> declarations.
>
> I prefer the simplicity of #2, but I also worry about the WTF impact it
> might have on evolving existing code.
>
> Can we get away with #2, or are we going to have to go with #3?  Are there
> other alternatives?
>
> Allen
>
>
>
>
>
>
>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>


-- 
Jeremy Martin
661.312.3853
http://devsmash.com
@jmar777
_

eval of let, etc. Was: Re: restrictions on let declarations

[Allen Wirfs-Brock]

On Feb 14, 2014, at 5:49 AM, André Bargull wrote:
>> 
>> How about this? 
>> 
>> let x= 0;
>> if (1) eval("let x= 42; alert(x);"); //Is this in its own block?
>> alert(x);
> 
> `eval()` hasn't yet been updated to work with the new lexical declaration 
> forms, but I hope the example from above will be evaluated in a new block. 
> See https://bugs.ecmascript.org/show_bug.cgi?id=1788 for a related bug report.

Goood point and this is something I need to specify in the next couple weeks so 
let's look at the alternatives.

First a quick refresher on ES5 era eval.

In ES5, the binding behavior of direct eval differs between strict and 
non-strict modes.

In strict mode, each eval instantiates all declarations in a new environment 
that is immediately nested within the current LexicalEnvironment. The scoping 
behavior is essentially the same as if the eval code was the body of an iife 
that occurred at the same place as the eval call.  Bindings introduced by the 
eval code disappear after completion of the eval.

In non-strict mode, each eval instantiates all declarations in the current 
VariableEnvironment; that is the most immediately enclosing function or global 
environment.  Bindings introduced by the eval code remain accessible from that 
VariableEnvironment after completion of the eval.

For example:
(function() {
  "use strict";
  eval("var answer=42");
  console.log(answer);  // ReferenceError: answer is not defined
})();

(function() { 
  eval("var answer=42");
  console.log(answer);  // 42
})();

For ES6, it makes sense for strict mode evals to behave in this exact same way. 
Each eval takes place in its own environment and no bindings survive the 
completion of the eval.

For ES6, non-strict evals of code containing only var or function declarations 
must  have exactly the ES5 behavior  in order to maintain compatibility.  But 
what about eval code that contains new declaration forms (let/const/class) 
exclusively or in combination with var/function declarations? Three 
possibilities come to mind:

1) Extend the ES5 semantics to include the new declaration forms.  For example:

(function() { 
  eval("let answer=42");
  console.log(answer);  // 42
})();

2) Use the strict mode binding semantics  if the eval code directly contains 
any of the new declaration forms:

(function() { 
  eval("
  var answer=42;
  let forceSeprateEnvironment = true;
   ");
  console.log(answer);  // ReferenceError: answer is not defined
})();

3) Combination.  use ES5 non-strict binding semantics for var/function 
declarations but place let/const/class bindings into a per eval environment:

(function() { 
  eval("
  var answer=42;
  let localToEval = true;
   ");
  console.log(answer);  // 42
  console.log(localToEval);  // ReferenceError: localToEval is not defined
)();


It would certainly be possible to specify #1, but I don't like it. Other than 
for the global environment it would be cleaner if the new block scope-able 
declarations  were never dynamically added to the environment.

I think either #2 or #3 is plausible.  #2 is a simpler story but introduces a 
refactoring hazard. If you have some existing eval code that  defines some 
"global" functions or variables, then simply adding a let/const/class 
declaration to the eval code ruins those global declarations. 

I prefer the simplicity of #2, but I also worry about the WTF impact it might 
have on evolving existing code.

Can we get away with #2, or are we going to have to go with #3?  Are there 
other alternatives?

Allen







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

Re: restrictions on let declarations

[André Bargull]

On 30/01/2014, at 17:13, Brendan Eich wrote:
/
/>/  
/>/  Interesting!
/>/  
/>/  You don't want the alert to show undefined, so the extent of the inner binding in your model is the unbraced consequent of the  "if".
/>/  
/>/  That is not "block scope" in any plain sense.

/

How about this?

let x= 0;
if (1) eval("let x= 42; alert(x);"); //Is this in its own block?
alert(x);


`eval()` hasn't yet been updated to work with the new lexical 
declaration forms, but I hope the example from above will be evaluated 
in a new block. See https://bugs.ecmascript.org/show_bug.cgi?id=1788 for 
a related bug report.


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

Re: restrictions on let declarations

[Jorge Chamorro]

On 30/01/2014, at 17:13, Brendan Eich wrote:

> John Barton wrote:
>> 
>> On Thu, Jan 30, 2014 at 7:54 AM, Brendan Eich > > wrote:
>> 
>>John Lenz wrote:
>> 
>>Generally, I've always thought of:
>> 
>>"if (x) ..." as equivalent to "if (x) { ... }"
>> 
>> 
>>let and const (and class) are block-scoped. {...} in your "if (x)
>>{...}" is a block. An unbraced consequent is not a block, and you
>>can't have a "conditional let binding".
>> 
>>The restriction avoids nonsense such as
>> 
>>let x = 0; { if (y) let x = 42; alert(x); }
>> 
>>What pray tell is going on here, in your model?
>> 
>> 
>> I'm with John: the alert should say 0 and I can't see why that is not 
>> obvious.
> 
> Interesting!
> 
> You don't want the alert to show undefined, so the extent of the inner 
> binding in your model is the unbraced consequent of the  "if".
> 
> That is not "block scope" in any plain sense.


How about this? 

let x= 0;
if (1) eval("let x= 42; alert(x);"); //Is this in its own block?
alert(x);


On 31/01/2014, at 03:11, Brendan Eich wrote:

> OMG LETS MAKE USELESS LETS EVERYWHERE LOLJSSUXZ0RZ! Um, no.

:-)

-- 
( Jorge )();
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: restrictions on let declarations

[Brendan Eich]

Thaddee Tyl wrote:

By the way, even in the current specification of let, we can still
construct a useless let:

 for (let x = 42;false;) console.log(x);

(which is the same as the example you gave, using "if").


Yes, this falls out of the JS (and Dart, convergent evolution, 
coincidental as far as I can tell) design, but so what? OMG LETS MAKE 
USELESS LETS EVERYWHERE LOLJSSUXZ0RZ! Um, no.


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

Re: restrictions on let declarations

[Thaddee Tyl]

On Thu, Jan 30, 2014 at 8:27 PM, John Lenz  wrote:
> I don't argue that it isn't a useless "let".

For the sake of argument, can you construct a non-block-scoped `if (…)
…` which is actually any useful, assuming your mental model of

if (…) … <==> if (…) { … }

(which must be removed from teaching material) applies?

By the way, even in the current specification of let, we can still
construct a useless let:

for (let x = 42;false;) console.log(x);

(which is the same as the example you gave, using "if").
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: restrictions on let declarations

[Brendan Eich]

John Lenz wrote:
I don't argue that it isn't a useless "let".  I do point out that in 
"sloppy" mode, that other declaration are allow in practices by 
browsers.  Chrome allows function, const, and var in the body of an if 
without block.


But those aren't useless.

They are quirky, but they do not bind in the consequent only, which is 
exactly what you and John said you wanted for if(x)let y=z.


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

Re: restrictions on let declarations

[Rick Waldron]

On Thu, Jan 30, 2014 at 2:59 PM, John Lenz  wrote:

> Yes, that was my point, that is has to be allowed currently and this is a
> change.
>

But let and const aren't the same as var and function, they have different
syntax with different static and runtime semantics. New forms are allowed
to have new rules, especially ones that make writing code with the new
forms more intuitive and less error prone.

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

Re: restrictions on let declarations

[John Lenz]

Yes, that was my point, that is has to be allowed currently and this is a
change.  Using what incorrectly? Existing "const" and "function"
implementations?  Or if "scoped" declarations?


On Thu, Jan 30, 2014 at 11:35 AM, Oliver Hunt  wrote:

>
> On Jan 30, 2014, at 11:27 AM, John Lenz  wrote:
>
> I don't argue that it isn't a useless "let".  I do point out that in
> "sloppy" mode, that other declaration are allow in practices by browsers.
>  Chrome allows function, const, and var in the body of an if without block.
>
>
> That's because they _have_ to be allowed as these constructs are used on
> millions (billions?) of web pages.  Disallowing that behaviour would break
> the web and we can't do that.
>
> Introducing new constructs that expose the same coding problems is not
> worth it - maybe we would want to change something in the future but we
> would already have been burned by existing content using this code
> incorrectly.
>
> --Oliver
>
>
> It does seems like an unnecessary restriction, and with it I'll need to
> make sure that Closure Compiler doesn't introduce these when stripping
> blocks, not a big deal just one more thing to deal with.
>
> I was just hoping that the restriction was enabling something and not just
> noise.
>
>
> On Thu, Jan 30, 2014 at 11:00 AM, Brendan Eich wrote:
>
>> John Barton wrote:
>>
>>>  Not silly. Can you suggest any on-line that most JS developers can
>>> understand discussing how these two forms differ?
>>>
>>> Here are some that describe them as equivalent:
>>>
>>> http://en.wikipedia.org/wiki/JavaScript_syntax#If_..._else
>>> http://msdn.microsoft.com/en-us/library/kw1tezhk(v=vs.94).aspx <
>>> http://msdn.microsoft.com/en-us/library/kw1tezhk%28v=vs.94%29.aspx>
>>>
>>> http://programmers.stackexchange.com/questions/
>>> 16528/single-statement-if-block-braces-or-no
>>> http://publib.boulder.ibm.com/infocenter/comphelp/v7v91/
>>> index.jsp?topic=%2Fcom.ibm.vacpp7a.doc%2Flanguage%2Fref%2Fclrc08csor.htm
>>> http://msdn.microsoft.com/en-us/library/ms173143.aspx
>>>
>>> and so on across multiple languages.  Whether or not you think these
>>> forms should be different, programmers don't expect them to differ.
>>>
>>
>> This is all beside the point, since the unbraced let as consequent of if
>> cannot make a useful binding (if you use comma-separated multiple
>> declarators, you still can't use any of the values that initialize the
>> bindings except in later useless-outside-the-single-declaration
>> consequent).
>>
>> /be
>>
>
> ___
> 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: restrictions on let declarations

[Rick Waldron]

On Thu, Jan 30, 2014 at 2:27 PM, John Lenz  wrote:

> I don't argue that it isn't a useless "let".  I do point out that in
> "sloppy" mode, that other declaration are allow in practices by browsers.
>  Chrome allows function, const, and var in the body of an if without block.
>
>

Did you mean to include const? Only IE11 has implemented const and let with
the proper semantics (with the exception of the for loop let binding
mistake, which will be corrected).

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

Re: restrictions on let declarations

[Oliver Hunt]

On Jan 30, 2014, at 11:27 AM, John Lenz  wrote:

> I don't argue that it isn't a useless "let".  I do point out that in "sloppy" 
> mode, that other declaration are allow in practices by browsers.  Chrome 
> allows function, const, and var in the body of an if without block.  
That’s because they _have_ to be allowed as these constructs are used on 
millions (billions?) of web pages.  Disallowing that behaviour would break the 
web and we can’t do that.

Introducing new constructs that expose the same coding problems is not worth it 
- maybe we would want to change something in the future but we would already 
have been burned by existing content using this code incorrectly.

—Oliver

> 
> It does seems like an unnecessary restriction, and with it I'll need to make 
> sure that Closure Compiler doesn't introduce these when stripping blocks, not 
> a big deal just one more thing to deal with.
> 
> I was just hoping that the restriction was enabling something and not just 
> noise.
> 
> 
> On Thu, Jan 30, 2014 at 11:00 AM, Brendan Eich  wrote:
> John Barton wrote:
>  Not silly. Can you suggest any on-line that most JS developers can 
> understand discussing how these two forms differ?
> 
> Here are some that describe them as equivalent:
> 
> http://en.wikipedia.org/wiki/JavaScript_syntax#If_..._else
> http://msdn.microsoft.com/en-us/library/kw1tezhk(v=vs.94).aspx 
> 
> 
> http://programmers.stackexchange.com/questions/16528/single-statement-if-block-braces-or-no
> http://publib.boulder.ibm.com/infocenter/comphelp/v7v91/index.jsp?topic=%2Fcom.ibm.vacpp7a.doc%2Flanguage%2Fref%2Fclrc08csor.htm
> http://msdn.microsoft.com/en-us/library/ms173143.aspx
> 
> and so on across multiple languages.  Whether or not you think these forms 
> should be different, programmers don't expect them to differ.
> 
> This is all beside the point, since the unbraced let as consequent of if 
> cannot make a useful binding (if you use comma-separated multiple 
> declarators, you still can't use any of the values that initialize the 
> bindings except in later useless-outside-the-single-declaration consequent).
> 
> /be
> 
> ___
> 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: restrictions on let declarations

[John Lenz]

I don't argue that it isn't a useless "let".  I do point out that in
"sloppy" mode, that other declaration are allow in practices by browsers.
 Chrome allows function, const, and var in the body of an if without block.


It does seems like an unnecessary restriction, and with it I'll need to
make sure that Closure Compiler doesn't introduce these when stripping
blocks, not a big deal just one more thing to deal with.

I was just hoping that the restriction was enabling something and not just
noise.


On Thu, Jan 30, 2014 at 11:00 AM, Brendan Eich  wrote:

> John Barton wrote:
>
>>  Not silly. Can you suggest any on-line that most JS developers can
>> understand discussing how these two forms differ?
>>
>> Here are some that describe them as equivalent:
>>
>> http://en.wikipedia.org/wiki/JavaScript_syntax#If_..._else
>> http://msdn.microsoft.com/en-us/library/kw1tezhk(v=vs.94).aspx <
>> http://msdn.microsoft.com/en-us/library/kw1tezhk%28v=vs.94%29.aspx>
>>
>> http://programmers.stackexchange.com/questions/16528/single-statement-if-
>> block-braces-or-no
>> http://publib.boulder.ibm.com/infocenter/comphelp/v7v91/
>> index.jsp?topic=%2Fcom.ibm.vacpp7a.doc%2Flanguage%2Fref%2Fclrc08csor.htm
>> http://msdn.microsoft.com/en-us/library/ms173143.aspx
>>
>> and so on across multiple languages.  Whether or not you think these
>> forms should be different, programmers don't expect them to differ.
>>
>
> This is all beside the point, since the unbraced let as consequent of if
> cannot make a useful binding (if you use comma-separated multiple
> declarators, you still can't use any of the values that initialize the
> bindings except in later useless-outside-the-single-declaration
> consequent).
>
> /be
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: restrictions on let declarations

[Brendan Eich]

John Barton wrote:
 Not silly. Can you suggest any on-line that most JS developers can 
understand discussing how these two forms differ?


Here are some that describe them as equivalent:

http://en.wikipedia.org/wiki/JavaScript_syntax#If_..._else
http://msdn.microsoft.com/en-us/library/kw1tezhk(v=vs.94).aspx 


http://programmers.stackexchange.com/questions/16528/single-statement-if-block-braces-or-no
http://publib.boulder.ibm.com/infocenter/comphelp/v7v91/index.jsp?topic=%2Fcom.ibm.vacpp7a.doc%2Flanguage%2Fref%2Fclrc08csor.htm
http://msdn.microsoft.com/en-us/library/ms173143.aspx

and so on across multiple languages.  Whether or not you think these 
forms should be different, programmers don't expect them to differ.


This is all beside the point, since the unbraced let as consequent of if 
cannot make a useful binding (if you use comma-separated multiple 
declarators, you still can't use any of the values that initialize the 
bindings except in later useless-outside-the-single-declaration consequent).


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

Re: restrictions on let declarations

[Rick Waldron]

On Thu, Jan 30, 2014 at 12:24 PM, Brendan Eich  wrote:

> Rick Waldron wrote:
>
>>
>> It is -- special forms that have heads can bind in bodies. We see
>> this with formal parameters to functions, also with the defunct
>> let blocks and let expressions of ES4. ML has similar forms.
>>
>> We made this block scoping, and how! Turns out Dart did the same.
>> Each iteration gets a fresh binding. If there's a closure in the
>> first part of the for(;;) head that captures the loop variable, it
>> gets a "0th iteration" binding.
>>
>>
>> Also, there was very positive interest in Waldemar's proposed if-scoped
>> let, here: https://mail.mozilla.org/pipermail/es-discuss/2013-
>> December/035077.html
>>
>
> Nick Krempel  proposed that upthread, just for the record.
>

Yes, my mistake--I had looked in December archives and found what I thought
was the OP. This is the correct OP from November:

https://mail.mozilla.org/pipermail/es-discuss/2013-November/035060.html


Rick


>
> Yeah, it's good. It comes from C++ but goes back to Algol, IIRC. Another
> precedent for block-scoped bindings that are declared in heads.
>
> /be
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: restrictions on let declarations

[John Barton]

On Thu, Jan 30, 2014 at 8:59 AM, Brendan Eich  wrote:

> John Lenz wrote:
>
>> In my model
>>
>> if (y) let x = 42
>>
>> is equivalent to
>>
>> if (y) {
>>   let x = 42
>> }
>>
>> and it is clear "x" in "alert(x)" is 0;
>>
>
> It is as clear as those invisible braces in your model's input :-P.
>
> Come on, this is silly.


Not silly. Can you suggest any on-line that most JS developers can
understand discussing how these two forms differ?

Here are some that describe them as equivalent:

http://en.wikipedia.org/wiki/JavaScript_syntax#If_..._else
http://msdn.microsoft.com/en-us/library/kw1tezhk(v=vs.94).aspx
http://programmers.stackexchange.com/questions/16528/single-statement-if-block-braces-or-no
http://publib.boulder.ibm.com/infocenter/comphelp/v7v91/index.jsp?topic=%2Fcom.ibm.vacpp7a.doc%2Flanguage%2Fref%2Fclrc08csor.htm
http://msdn.microsoft.com/en-us/library/ms173143.aspx

and so on across multiple languages.  Whether or not you think these forms
should be different, programmers don't expect them to differ.

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

Re: restrictions on let declarations

[Brendan Eich]

Rick Waldron wrote:


It is -- special forms that have heads can bind in bodies. We see
this with formal parameters to functions, also with the defunct
let blocks and let expressions of ES4. ML has similar forms.

We made this block scoping, and how! Turns out Dart did the same.
Each iteration gets a fresh binding. If there's a closure in the
first part of the for(;;) head that captures the loop variable, it
gets a "0th iteration" binding.


Also, there was very positive interest in Waldemar's proposed 
if-scoped let, here: 
https://mail.mozilla.org/pipermail/es-discuss/2013-December/035077.html


Nick Krempel  proposed that upthread, just for the record.

Yeah, it's good. It comes from C++ but goes back to Algol, IIRC. Another 
precedent for block-scoped bindings that are declared in heads.

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

Re: restrictions on let declarations

[Rick Waldron]

On Thu, Jan 30, 2014 at 12:10 PM, Brendan Eich  wrote:

> John Lenz wrote:
>
>> How did "let x" in for-loops land:
>>
>> for (let x = 1; x < 10 ; i++) {
>>   // is "x" a fresh binding for every iteration?
>> }
>>
>> This wouldn't be "block" scoping either.
>>
>
> It is -- special forms that have heads can bind in bodies. We see this
> with formal parameters to functions, also with the defunct let blocks and
> let expressions of ES4. ML has similar forms.
>
> We made this block scoping, and how! Turns out Dart did the same. Each
> iteration gets a fresh binding. If there's a closure in the first part of
> the for(;;) head that captures the loop variable, it gets a "0th iteration"
> binding.


Also, there was very positive interest in Waldemar's proposed if-scoped
let, here:
https://mail.mozilla.org/pipermail/es-discuss/2013-December/035077.html


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

Re: restrictions on let declarations

[Brendan Eich]

John Lenz wrote:

How did "let x" in for-loops land:

for (let x = 1; x < 10 ; i++) {
  // is "x" a fresh binding for every iteration?
}

This wouldn't be "block" scoping either.


It is -- special forms that have heads can bind in bodies. We see this 
with formal parameters to functions, also with the defunct let blocks 
and let expressions of ES4. ML has similar forms.


We made this block scoping, and how! Turns out Dart did the same. Each 
iteration gets a fresh binding. If there's a closure in the first part 
of the for(;;) head that captures the loop variable, it gets a "0th 
iteration" binding.


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

Re: restrictions on let declarations

[Brendan Eich]

John Lenz wrote:

In my model

if (y) let x = 42

is equivalent to

if (y) {
  let x = 42
}

and it is clear "x" in "alert(x)" is 0;


It is as clear as those invisible braces in your model's input :-P.

Come on, this is silly. "var" has quirks, but we are not propagating 
them to other forms, making implicit blocks where no braces exist, etc.


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

Re: restrictions on let declarations

[Rick Waldron]

On Thu, Jan 30, 2014 at 11:39 AM, John Lenz  wrote:

> How did "let x" in for-loops land:
>
> for (let x = 1; x < 10 ; i++) {
>   // is "x" a fresh binding for every iteration?
>

Yes.


> }
>
> This wouldn't be "block" scoping either.
>

See:
https://github.com/rwaldron/tc39-notes/blob/master/es6/2013-11/nov-20.md#consensusresolution-6


Rick



>
> On Thu, Jan 30, 2014 at 8:13 AM, Brendan Eich  wrote:
>
>> John Barton wrote:
>>
>>
>>> On Thu, Jan 30, 2014 at 7:54 AM, Brendan Eich >> bren...@mozilla.com>> wrote:
>>>
>>> John Lenz wrote:
>>>
>>> Generally, I've always thought of:
>>>
>>> "if (x) ..." as equivalent to "if (x) { ... }"
>>>
>>>
>>> let and const (and class) are block-scoped. {...} in your "if (x)
>>> {...}" is a block. An unbraced consequent is not a block, and you
>>> can't have a "conditional let binding".
>>>
>>> The restriction avoids nonsense such as
>>>
>>> let x = 0; { if (y) let x = 42; alert(x); }
>>>
>>> What pray tell is going on here, in your model?
>>>
>>>
>>> I'm with John: the alert should say 0 and I can't see why that is not
>>> obvious.
>>>
>>
>> Interesting!
>>
>> You don't want the alert to show undefined, so the extent of the inner
>> binding in your model is the unbraced consequent of the  "if".
>>
>> That is not "block scope" in any plain sense.
>>
>> /be
>>
>
>
> ___
> 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: restrictions on let declarations

[Jason Orendorff]

On Thu, Jan 30, 2014 at 8:26 AM, John Lenz  wrote:
> In my model
>
> if (y) let x = 42
>
> is equivalent to
>
> if (y) {
>   let x = 42
> }

Yes, everyone here understands your model. This is a question of
taste. There are competing senses of what is intuitive at play.

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

Re: restrictions on let declarations

[John Lenz]

How did "let x" in for-loops land:

for (let x = 1; x < 10 ; i++) {
  // is "x" a fresh binding for every iteration?
}

This wouldn't be "block" scoping either.


On Thu, Jan 30, 2014 at 8:13 AM, Brendan Eich  wrote:

> John Barton wrote:
>
>
>> On Thu, Jan 30, 2014 at 7:54 AM, Brendan Eich > bren...@mozilla.com>> wrote:
>>
>> John Lenz wrote:
>>
>> Generally, I've always thought of:
>>
>> "if (x) ..." as equivalent to "if (x) { ... }"
>>
>>
>> let and const (and class) are block-scoped. {...} in your "if (x)
>> {...}" is a block. An unbraced consequent is not a block, and you
>> can't have a "conditional let binding".
>>
>> The restriction avoids nonsense such as
>>
>> let x = 0; { if (y) let x = 42; alert(x); }
>>
>> What pray tell is going on here, in your model?
>>
>>
>> I'm with John: the alert should say 0 and I can't see why that is not
>> obvious.
>>
>
> Interesting!
>
> You don't want the alert to show undefined, so the extent of the inner
> binding in your model is the unbraced consequent of the  "if".
>
> That is not "block scope" in any plain sense.
>
> /be
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: restrictions on let declarations

[John Barton]

> On Thu, Jan 30, 2014 at 10:59 AM, John Barton
>
> That craziness is the whole point of block scoping let.  ...
>
> Give that this is the behaviour of every other block scoped language i
> don’t see why this is confusing.
>

It's not `let` vs `var` that concerns us, it's that the statement following
an if condition is not equivalent to a block.

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

Re: restrictions on let declarations

[John Lenz]

In my model

if (y) let x = 42

is equivalent to

if (y) {
  let x = 42
}

and it is clear "x" in "alert(x)" is 0;


On Thu, Jan 30, 2014 at 7:54 AM, Brendan Eich  wrote:

> John Lenz wrote:
>
>> Generally, I've always thought of:
>>
>> "if (x) ..." as equivalent to "if (x) { ... }"
>>
>
> let and const (and class) are block-scoped. {...} in your "if (x) {...}"
> is a block. An unbraced consequent is not a block, and you can't have a
> "conditional let binding".
>
> The restriction avoids nonsense such as
>
> let x = 0; { if (y) let x = 42; alert(x); }
>
> What pray tell is going on here, in your model?
>
> /be
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: restrictions on let declarations

[Oliver Hunt]

On Jan 30, 2014, at 8:07 AM, Dean Landolt  wrote:

> 
> 
> 
> On Thu, Jan 30, 2014 at 10:59 AM, John Barton  wrote:
> 
> 
> 
> On Thu, Jan 30, 2014 at 7:54 AM, Brendan Eich  wrote:
> John Lenz wrote:
> Generally, I've always thought of:
> 
> "if (x) ..." as equivalent to "if (x) { ... }"
> 
> let and const (and class) are block-scoped. {...} in your "if (x) {...}" is a 
> block. An unbraced consequent is not a block, and you can't have a 
> "conditional let binding".
> 
> The restriction avoids nonsense such as
> 
> let x = 0; { if (y) let x = 42; alert(x); }
> 
> What pray tell is going on here, in your model?
> 
> I'm with John: the alert should say 0 and I can't see why that is not obvious.
> 
> 
> It's not obvious at all -- what happens when you drop the initial `let x = 
> 0;` and you just have `{ if (y) let x = 42; alert(x); }` -- now what happens? 
> Is x declared or not?
> 
> To my mind `if (y) let x = 42;` reads like it's own 1-line noop block -- at 
> least, that's what I'd expect of the scope. So while it could be allowed in 
> that sense, it'd only serve as a footgun when y is true.

This is exactly foot gun the language restriction is intended to avoid.

Most modern [Obj-]C[++] will warn on this (well, s/let/int/)

You might be getting confused because of the bizarro var hoisting semantics of 
var

if (y) let x = “nope"; alert(x)

Results in an unusable binding of x, and so this would throw (the foot gun 
occurs if you’re shadowing x, that’s another shadow that i think C compilers 
will warn on), e.g..
y = true; let x = “whoops”; if (y) let x = “nope"; alert(x) // “whoops"

The var case

y = true; var x = “whoops”; if (y) var x = “nope"; alert(x); // “nope"

is actually interpreted as

var x; y= true; x = “whoops”; if (y) x = “nope”; alert(x); // “nope"

That craziness is the whole point of block scoping let.  More interestingly

if (window.SomeCrazyDomFeature) var foo = true;

is a common web idiom as it brings foo into scope for everything, so makes 
later "if (foo) “ statements safe.  Anyone trying to do this with a |let| would 
get incorrect (from their PoV) behaviour.  Again that’s why we error out.

Give that this is the behaviour of every other block scoped language i don’t 
see why this is confusing.

—Oliver

> ___
> 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: restrictions on let declarations

[Brendan Eich]

John Barton wrote:


On Thu, Jan 30, 2014 at 7:54 AM, Brendan Eich > wrote:


John Lenz wrote:

Generally, I've always thought of:

"if (x) ..." as equivalent to "if (x) { ... }"


let and const (and class) are block-scoped. {...} in your "if (x)
{...}" is a block. An unbraced consequent is not a block, and you
can't have a "conditional let binding".

The restriction avoids nonsense such as

let x = 0; { if (y) let x = 42; alert(x); }

What pray tell is going on here, in your model?


I'm with John: the alert should say 0 and I can't see why that is not 
obvious.


Interesting!

You don't want the alert to show undefined, so the extent of the inner 
binding in your model is the unbraced consequent of the  "if".


That is not "block scope" in any plain sense.

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

Re: restrictions on let declarations

[Dean Landolt]

On Thu, Jan 30, 2014 at 10:59 AM, John Barton wrote:

>
>
>
> On Thu, Jan 30, 2014 at 7:54 AM, Brendan Eich  wrote:
>
>> John Lenz wrote:
>>
>>> Generally, I've always thought of:
>>>
>>> "if (x) ..." as equivalent to "if (x) { ... }"
>>>
>>
>> let and const (and class) are block-scoped. {...} in your "if (x) {...}"
>> is a block. An unbraced consequent is not a block, and you can't have a
>> "conditional let binding".
>>
>> The restriction avoids nonsense such as
>>
>> let x = 0; { if (y) let x = 42; alert(x); }
>>
>> What pray tell is going on here, in your model?
>
>
> I'm with John: the alert should say 0 and I can't see why that is not
> obvious.
>


It's not obvious at all -- what happens when you drop the initial `let x =
0;` and you just have `{ if (y) let x = 42; alert(x); }` -- now what
happens? Is x declared or not?

To my mind `if (y) let x = 42;` reads like it's own 1-line noop block -- at
least, that's what I'd expect of the scope. So while it could be allowed in
that sense, it'd only serve as a footgun when y is true.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: restrictions on let declarations

[Allen Wirfs-Brock]

On Jan 30, 2014, at 7:43 AM, John Lenz wrote:

> It seems unfortunate that "let" and "const" have different usage rules from 
> "var".  It seem strange  that "var" is considered a statement and not 
> declaration as per:
> 
> http://people.mozilla.org/~jorendorff/es6-draft.html#sec-ecmascript-language-statements-and-declarations
> 
> Generally, I've always thought of:
> 
> "if (x) ..." as equivalent to "if (x) { ... }"
> 
> Does this restriction on let/const enable anything?
> 

The anomaly is that 'var' was considered a statement in ES1. But note that the 
only other declaration in the language ('function') at that time was not a 
statement. See http://www.wirfs-brock.com/allen/draft-ES5.1/#sec-14 

Declarations have global static impact within their containing scope (function 
or block). It generally doesn't make any sense to use them in a conditional 
context without an explicitly surrounding block that constrains their scope.

So all new declarative forms in ES6 are treated similarly to function.  They 
are declarations but not statements.  Var must remain a statement for legacy 
compatability.

Allen




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

Re: restrictions on let declarations

[John Barton]

On Thu, Jan 30, 2014 at 7:54 AM, Brendan Eich  wrote:

> John Lenz wrote:
>
>> Generally, I've always thought of:
>>
>> "if (x) ..." as equivalent to "if (x) { ... }"
>>
>
> let and const (and class) are block-scoped. {...} in your "if (x) {...}"
> is a block. An unbraced consequent is not a block, and you can't have a
> "conditional let binding".
>
> The restriction avoids nonsense such as
>
> let x = 0; { if (y) let x = 42; alert(x); }
>
> What pray tell is going on here, in your model?


I'm with John: the alert should say 0 and I can't see why that is not
obvious.


>
>
> /be
>
> ___
> 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: restrictions on let declarations

[Brendan Eich]

John Lenz wrote:

Generally, I've always thought of:

"if (x) ..." as equivalent to "if (x) { ... }"


let and const (and class) are block-scoped. {...} in your "if (x) {...}" 
is a block. An unbraced consequent is not a block, and you can't have a 
"conditional let binding".


The restriction avoids nonsense such as

let x = 0; { if (y) let x = 42; alert(x); }

What pray tell is going on here, in your model?

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

Re: restrictions on let declarations

[John Lenz]

It seems unfortunate that "let" and "const" have different usage rules from
"var".  It seem strange  that "var" is considered a statement and not
declaration as per:

http://people.mozilla.org/~jorendorff/es6-draft.html#sec-ecmascript-language-statements-and-declarations

Generally, I've always thought of:

"if (x) ..." as equivalent to "if (x) { ... }"

Does this restriction on let/const enable anything?





On Wed, Jan 29, 2014 at 10:31 PM, Erik Arvidsson
wrote:

> It falls out of the grammar.
>
> IfStatement can only contain Statement which does not include Declaration
> without going through a BlockStatement.
>
>
> On Wed, Jan 29, 2014 at 9:57 PM, John Lenz  wrote:
>
>>  I have some old notes that says that "let" can't be used in some
>> context where a var could like:
>>
>>   if (a) let x = 2;
>>
>> In my perusal of the spec I don't see that this is the case now.  Can
>> someone confirm that for me?
>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
>
> --
> erik
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: restrictions on let declarations

[Erik Arvidsson]

It falls out of the grammar.

IfStatement can only contain Statement which does not include Declaration
without going through a BlockStatement.


On Wed, Jan 29, 2014 at 9:57 PM, John Lenz  wrote:

> I have some old notes that says that "let" can't be used in some context
> where a var could like:
>
>   if (a) let x = 2;
>
> In my perusal of the spec I don't see that this is the case now.  Can
> someone confirm that for me?
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>


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