RE: Having a non-enumerable Array.prototype.contains may not beweb-compatible

[Andrea Giammarchi]

 many MDN examples are on jsfiddle ...maybe one of the reasons? Although I 
wasn't suggesting to break everything, rather saying that changing name should 
not be an option.

-Original Message-
From: "John-David Dalton" 
Sent: ‎01/‎10/‎2014 00:54
To: "Jason Orendorff" 
Cc: "Andrea Giammarchi" ; "es-discuss" 

Subject: Re: Having a non-enumerable Array.prototype.contains may not 
beweb-compatible

So put ES7 features behind a flag until the water clears a bit. We'll get there.

It kind of surprises me (a good surprise) that now, because of JSFiddle, 
there's super interest in MooTools. When in the past, when MooTools was 
arguably more popular, it didn't stop the language and browsers from breaking 
them over and over again.


JDD


On Tue, Sep 30, 2014 at 4:24 PM, Jason Orendorff  
wrote:

On Tue, Sep 30, 2014 at 5:35 PM, Andrea Giammarchi
 wrote:
> I'm personally against unmaintained code and/or websites but here it's not
> ES7 breaking the web, it's a library already broken (somehow) due native
> prototype pollution without a mechanism to prevent these, apparently
> historically known, problems.

Either way, you're telling me I should ship a browser that chokes on
thousands of web sites that work fine today. That would be bad for our
users, so I'm not planning on doing that.

> it is also already patched and it's also a small fix.

The 6.5% of existing web sites using JS libraries that use MooTools
have not been "already patched". Patching 3.5 million web sites is not
a "small fix" in any relevant sense. It simply will not be done
thoroughly or soon.

> If sites and developers have no reason to update code 'cause ES7 cannot
> release until they'll change a file ... why would they anyway.

Yes. You have correctly identified incentives as a problem.

That does not constitute a reductio proof that browser vendors must
ignore their users' interests and break the web. "Reductio ad
the-world-is-not-as-I-wish-it-to-be" is not a thing.

-j

___
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: Array.prototype.contains solutions

[Mark S. Miller]

On Tue, Sep 30, 2014 at 4:58 PM, Domenic Denicola <
dome...@domenicdenicola.com> wrote:

> This is a follow-up thread to discuss how to solve the problem identified
> in
> http://esdiscuss.org/topic/having-a-non-enumerable-array-prototype-contains-may-not-be-web-compatible
> without breaking the web. (Any arguments that it is OK to break sites using
> MooTools, please stay in that thread and respectfully do *not* reply to
> this one.)
>
> ---
>
> So, guess that proves I should never say "this will be easy!" before
> working on a feature. Yay, the web.
>
> I see a few options:
>
> 1. Rename. The leading candidate would be `Array.prototype.has`. I
> outlined in [1] why `contains` is better; note especially the DOM classes.
> But you could stretch things, especially by removing the `fromIndex`
> parameter, into an argument that `has` is OK. (Basically, you'd be saying
> that an array is more like a set than a map, and that its analogy with
> String is mostly accidental.)
>

If we do rename, it should be almost anything other than .has. Arrays are
clearly single-valued-mapping-like, not set-like, in that they map from
indexes to values. If Array.prototype.has were to exist, it would need to
test possible indexes.



>
> 2. Specific hacks. I am thinking of e.g. making `Array.prototype.contains`
> a getter, with a setter that does [[DefineOwnProperty]].
>

This could work, and it requires no new kernel mechanisms. If we do adopt
this solution, the setter should be careful to play the same games that SES
plays to work around the override mistake: If the this being set is not
Array.prototype itself, the setter should use [[DefineOwnProperty]] to
emulate an assignment to that this's own .contains.


>
> 3. General hacks. I joked about @@unMooToolsables, but seriously, we could
> do something similar to @@unscopables of using MOP hooks to fix this
> problem. One idea that seems reasonable is @@enumerableWhenAssigned, so
> that `Array.prototype.contains` starts non-enumerable, but when you do
> `Array.prototype.contains = x`, it becomes enumerable. You could even
> generalize this into something that also fixes the override mistake [2],
> e.g. @@defineOwnPropertyOnAssign or @@assignIgnoresProto or similar. Or you
> could attack the problem at the for-in level
>

I suggest we focus on the override mistake. If we come up with a way of
fixing it and .contains with one new kernel mechanism, that would be great.
If we only fix the override mistake, still likely worth it. But if a new
kernel mechanism only fixes .contains, it likely isn't worth it and we
should return to #1 or #2.




>
> ---
>
> 1 is tempting in its simplicity. 2 is pretty gross and we'd probably be
> better of throwing out the feature. 3 is intriguing, although it obviously
> adds complexity cost to a feature that was supposed to be trivial.
>
> I am curious if there is any support for 3, or proposals for a better hack
> in that vein. Because we will also have this problem for any other
> prototype extensions that work in the same way, e.g. MooTools's `flatten`
> (which seems like something we'd likely want) or their `associate`, `link`,
> `getRandom`, `combine`, or `pick` (which seem less likely). And I assume
> the problem could extend beyond MooTools, and possibly beyond Array.
> (Although, Array is a special case in that we can't make any of its methods
> enumerable.)
>
> Especially if we choose something more general, e.g. @@assignIgnoresProto,
> I could see this being a powerful tool for fighting such problems in the
> future, and maybe for helping fix the override mistake (although I don't
> understand all of the use cases involved there).
>
> [1]:
> https://github.com/domenic/Array.prototype.contains/#why-contains-instead-of-has
> [2]:
> http://wiki.ecmascript.org/doku.php?id=strawman:fixing_override_mistake


The most painful use case is the existence of perfectly reasonable ES5 code
like:


function Point(x, y) { this.x = x; this.y = y; }

Point.prototype.toString() { return `<${x},${y}>`; };

Because of the override mistake, this reasonable code no longer works after

Object.freeze(Object.prototype);

This sucks.

SES goes out of its way to not break code that follows ES5 best practices.
The above Point code does. That's why SES's tamperProof(Object.prototype)
replaces the data properties on Object.prototype with accessor properties
whose setter uses [[DefineOwnProperty]] to emulate assignment on a this
that is not Object.prototype itself.

With your #3, perhaps we'd have a less painful way to working around the
override mistake.


>
> ___
> 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: Throwing errors on mutating immutable bindings

[Allen Wirfs-Brock]

On Sep 30, 2014, at 5:09 PM, Shu-yu Guo wrote:

> Hi all,
> 
> In the current draft, I see 2 different places where assigning to an 
> immutable binding ('const') throws an error:
> 
> 1) Dynamically throwing a TypeError in SetMutableBinding, 
> http://people.mozilla.org/~jorendorff/es6-draft.html#sec-declarative-environment-records-setmutablebinding-n-v-s
> 2) Statically throwing a Syntax Error in assignment expressions, 
> http://people.mozilla.org/~jorendorff/es6-draft.html#sec-assignment-operators-static-semantics-early-errors
see bug https://bugs.ecmascript.org/show_bug.cgi?id=3148 the "can" in that 
sentence isn't meant to be interpreted as "best effort" but instead more along 
the lines of "it is provable".

We need to refine that language, but the test is approximately that there are 
no with blocks inside the scope of the const declaration and surrounding the 
reference to the const. binding

> 
> 1) throws only in strict mode code, while 2) throws regardless. 2) is also 
> best effort; seems to be implementation-dependent what "can statically 
> determine" entails.
> 
> Is the intention that assigning to consts silently nops if the implementation 
> cannot determine the assignment to be to a const statically, in non-strict 
> code, but implementations *should* make a best effort to report such cases 
> eagerly, regardless of strictness? Seems kind of odd to me; perhaps I am 
> misreading?

1) looks like a bug to me.  I pretty sure it was never the intent for 
assignments to const binding to silently fail in non-strict code. The current 
semantics of SetMutableBinding is a carry over from ES5 where immutable 
bindings were only used (I have to double check this) for FunctionExpression 
function name bindings. The legacy of ES3 (hence non-strict ES5) was to did not 
throw on assignments to such function name bindings.

I'll probably have to do some extra special casing to preserve the ES3/5 
semantics for assignment to function names and make the throw unconditional to 
other immutable bindings

Allen


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

Re: Maximally minimal stack trace standardization

[Carl Smith]

Sorry, I didn't mean to kind of hijack the thread. Just read it back.
Really just wanted to share the point of view of someone who actually has
to provide tracebacks to the user as a central feature in an app. It's
difficult, but doable, but only in Chrome/Opera. Pragmatically, it'd just
be nice if FireFox did the named eval thing so it wasn't an engine specific
hack. That'd be close enough to a standard for a lot of cases. Other
vendors are what they are.

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

Re: Array.prototype.contains solutions

[John-David Dalton]

Maybe.
Though there would still be issues with implementations not aligning, like
Ember which does use defineProperty to make them non-enumerable and doesn't
pave existing methods,
as well as issues with scripts that support pre-ES5 environments that don't
want enumerable inconsistency.

JDD


On Tue, Sep 30, 2014 at 5:15 PM, Boris Zbarsky  wrote:

> On 9/30/14, 8:12 PM, John-David Dalton wrote:
>
>> Extending native prototypes is a JavaScript "thing" and something that
>> will most likely continue continue.
>>
>
> Note that if people were extending in nice ways, using defineProperty and
> making their props non-enumerable instead of just doing a [[Set]], that
> would significantly reduce issues like this...
>
> -Boris
>
> ___
> 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: Array.prototype.contains solutions

[Boris Zbarsky]

On 9/30/14, 8:12 PM, John-David Dalton wrote:

Extending native prototypes is a JavaScript "thing" and something that
will most likely continue continue.


Note that if people were extending in nice ways, using defineProperty 
and making their props non-enumerable instead of just doing a [[Set]], 
that would significantly reduce issues like this...


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

Re: Array.prototype.contains solutions

[John-David Dalton]

A more general solution seems like a good idea.
Renaming doesn't really solve the deeper issue.
Extending native prototypes is a JavaScript "thing" and something that will
most likely continue continue.

Ember adds methods to Array.prototype and Function.prototype by default:
http://emberjs.com/api/classes/Ember.Array.html#method_contains (btw their
Array#contains is not ES7 spec compliant either)

then there's the oldie Prototype.js:
http://api.prototypejs.org/

and alternatives like Sugar.js:
http://sugarjs.com/api

that's a lot to watch out for.

JDD


On Tue, Sep 30, 2014 at 5:03 PM, Domenic Denicola <
dome...@domenicdenicola.com> wrote:

> From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of
> Domenic Denicola
>
> > Or you could attack the problem at the for-in level
>
> This half-sentence was a leftover from an earlier pass; please ignore it.
>
> ___
> 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

Throwing errors on mutating immutable bindings

[Shu-yu Guo]

Hi all,

In the current draft, I see 2 different places where assigning to an immutable 
binding ('const') throws an error:

1) Dynamically throwing a TypeError in SetMutableBinding, 
http://people.mozilla.org/~jorendorff/es6-draft.html#sec-declarative-environment-records-setmutablebinding-n-v-s
2) Statically throwing a Syntax Error in assignment expressions, 
http://people.mozilla.org/~jorendorff/es6-draft.html#sec-assignment-operators-static-semantics-early-errors

1) throws only in strict mode code, while 2) throws regardless. 2) is also best 
effort; seems to be implementation-dependent what "can statically determine" 
entails.

Is the intention that assigning to consts silently nops if the implementation 
cannot determine the assignment to be to a const statically, in non-strict 
code, but implementations *should* make a best effort to report such cases 
eagerly, regardless of strictness? Seems kind of odd to me; perhaps I am 
misreading?

-- 
shu

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

RE: Array.prototype.contains solutions

[Domenic Denicola]

From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Domenic 
Denicola

> Or you could attack the problem at the for-in level

This half-sentence was a leftover from an earlier pass; please ignore it.

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

Array.prototype.contains solutions

[Domenic Denicola]

This is a follow-up thread to discuss how to solve the problem identified in 
http://esdiscuss.org/topic/having-a-non-enumerable-array-prototype-contains-may-not-be-web-compatible
 without breaking the web. (Any arguments that it is OK to break sites using 
MooTools, please stay in that thread and respectfully do *not* reply to this 
one.)

---

So, guess that proves I should never say "this will be easy!" before working on 
a feature. Yay, the web.

I see a few options:

1. Rename. The leading candidate would be `Array.prototype.has`. I outlined in 
[1] why `contains` is better; note especially the DOM classes. But you could 
stretch things, especially by removing the `fromIndex` parameter, into an 
argument that `has` is OK. (Basically, you'd be saying that an array is more 
like a set than a map, and that its analogy with String is mostly accidental.)

2. Specific hacks. I am thinking of e.g. making `Array.prototype.contains` a 
getter, with a setter that does [[DefineOwnProperty]].

3. General hacks. I joked about @@unMooToolsables, but seriously, we could do 
something similar to @@unscopables of using MOP hooks to fix this problem. One 
idea that seems reasonable is @@enumerableWhenAssigned, so that 
`Array.prototype.contains` starts non-enumerable, but when you do 
`Array.prototype.contains = x`, it becomes enumerable. You could even 
generalize this into something that also fixes the override mistake [2], e.g. 
@@defineOwnPropertyOnAssign or @@assignIgnoresProto or similar. Or you could 
attack the problem at the for-in level

---

1 is tempting in its simplicity. 2 is pretty gross and we'd probably be better 
of throwing out the feature. 3 is intriguing, although it obviously adds 
complexity cost to a feature that was supposed to be trivial.

I am curious if there is any support for 3, or proposals for a better hack in 
that vein. Because we will also have this problem for any other prototype 
extensions that work in the same way, e.g. MooTools's `flatten` (which seems 
like something we'd likely want) or their `associate`, `link`, `getRandom`, 
`combine`, or `pick` (which seem less likely). And I assume the problem could 
extend beyond MooTools, and possibly beyond Array. (Although, Array is a 
special case in that we can't make any of its methods enumerable.)

Especially if we choose something more general, e.g. @@assignIgnoresProto, I 
could see this being a powerful tool for fighting such problems in the future, 
and maybe for helping fix the override mistake (although I don't understand all 
of the use cases involved there).

[1]: 
https://github.com/domenic/Array.prototype.contains/#why-contains-instead-of-has
[2]: http://wiki.ecmascript.org/doku.php?id=strawman:fixing_override_mistake

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

RE: Having a non-enumerable Array.prototype.contains may not be web-compatible

[Domenic Denicola]

You guys are much more optimistic than I am about this ever being shippable. I 
am starting a new thread to investigate solutions that don’t involve waiting 
for indeterminate amounts of time, but of course if we can somehow fix the 
MooTools-using web and not change anything about Array.prototype.contains, that 
would be ideal.

From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of 
John-David Dalton
Sent: Wednesday, October 1, 2014 00:55
To: Jason Orendorff
Cc: es-discuss
Subject: Re: Having a non-enumerable Array.prototype.contains may not be 
web-compatible

So put ES7 features behind a flag until the water clears a bit. We'll get there.
It kind of surprises me (a good surprise) that now, because of JSFiddle, 
there's super interest in MooTools. When in the past, when MooTools was 
arguably more popular, it didn't stop the language and browsers from breaking 
them over and over again.

JDD

On Tue, Sep 30, 2014 at 4:24 PM, Jason Orendorff 
mailto:jason.orendo...@gmail.com>> wrote:
On Tue, Sep 30, 2014 at 5:35 PM, Andrea Giammarchi
mailto:andrea.giammar...@gmail.com>> wrote:
> I'm personally against unmaintained code and/or websites but here it's not
> ES7 breaking the web, it's a library already broken (somehow) due native
> prototype pollution without a mechanism to prevent these, apparently
> historically known, problems.

Either way, you're telling me I should ship a browser that chokes on
thousands of web sites that work fine today. That would be bad for our
users, so I'm not planning on doing that.

> it is also already patched and it's also a small fix.

The 6.5% of existing web sites using JS libraries that use MooTools
have not been "already patched". Patching 3.5 million web sites is not
a "small fix" in any relevant sense. It simply will not be done
thoroughly or soon.

> If sites and developers have no reason to update code 'cause ES7 cannot
> release until they'll change a file ... why would they anyway.

Yes. You have correctly identified incentives as a problem.

That does not constitute a reductio proof that browser vendors must
ignore their users' interests and break the web. "Reductio ad
the-world-is-not-as-I-wish-it-to-be" is not a thing.

-j
___
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: Having a non-enumerable Array.prototype.contains may not be web-compatible

[John-David Dalton]

So put ES7 features behind a flag until the water clears a bit. We'll get
there.
It kind of surprises me (a good surprise) that now, because of JSFiddle,
there's super interest in MooTools. When in the past, when MooTools was
arguably more popular, it didn't stop the language and browsers from
breaking them over and over again.

JDD

On Tue, Sep 30, 2014 at 4:24 PM, Jason Orendorff 
wrote:

> On Tue, Sep 30, 2014 at 5:35 PM, Andrea Giammarchi
>  wrote:
> > I'm personally against unmaintained code and/or websites but here it's
> not
> > ES7 breaking the web, it's a library already broken (somehow) due native
> > prototype pollution without a mechanism to prevent these, apparently
> > historically known, problems.
>
> Either way, you're telling me I should ship a browser that chokes on
> thousands of web sites that work fine today. That would be bad for our
> users, so I'm not planning on doing that.
>
> > it is also already patched and it's also a small fix.
>
> The 6.5% of existing web sites using JS libraries that use MooTools
> have not been "already patched". Patching 3.5 million web sites is not
> a "small fix" in any relevant sense. It simply will not be done
> thoroughly or soon.
>
> > If sites and developers have no reason to update code 'cause ES7 cannot
> > release until they'll change a file ... why would they anyway.
>
> Yes. You have correctly identified incentives as a problem.
>
> That does not constitute a reductio proof that browser vendors must
> ignore their users' interests and break the web. "Reductio ad
> the-world-is-not-as-I-wish-it-to-be" is not a thing.
>
> -j
> ___
> 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: Having a non-enumerable Array.prototype.contains may not be web-compatible

[Rick Waldron]

On Tue, Sep 30, 2014 at 7:24 PM, Jason Orendorff 
wrote:

> On Tue, Sep 30, 2014 at 5:35 PM, Andrea Giammarchi
>  wrote:
> > I'm personally against unmaintained code and/or websites but here it's
> not
> > ES7 breaking the web, it's a library already broken (somehow) due native
> > prototype pollution without a mechanism to prevent these, apparently
> > historically known, problems.
>
> Either way, you're telling me I should ship a browser that chokes on
> thousands of web sites that work fine today. That would be bad for our
> users, so I'm not planning on doing that.
>

I support your decision to back it out for now and the foreseeable future.
This will give devs a chance to evangelize the necessary updates.

Rick


>
> > it is also already patched and it's also a small fix.
>
> The 6.5% of existing web sites using JS libraries that use MooTools
> have not been "already patched". Patching 3.5 million web sites is not
> a "small fix" in any relevant sense. It simply will not be done
> thoroughly or soon.
>
> > If sites and developers have no reason to update code 'cause ES7 cannot
> > release until they'll change a file ... why would they anyway.
>
> Yes. You have correctly identified incentives as a problem.
>
> That does not constitute a reductio proof that browser vendors must
> ignore their users' interests and break the web. "Reductio ad
> the-world-is-not-as-I-wish-it-to-be" is not a thing.
>
> -j
> ___
> 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: Having a non-enumerable Array.prototype.contains may not be web-compatible

[Rick Waldron]

On Tue, Sep 30, 2014 at 6:04 PM, Jason Orendorff 
wrote:

> On Tue, Sep 30, 2014 at 1:45 PM, Michał Wadas 
> wrote:
> > Bug in MooTools is not a reason to make any method of Array.prototype
> > enumerable.
>
> Well -- true, that would break even more sites.
>
> We're backing out Array#contains() for now. It's disappointing to me
> personally -- that was a volunteer contribution. In the long run,
> perhaps renaming it is the best course? :-\
>

Unfortunately, it's named to match String.prototype.contains and Domenic
made strong cases in his proposal and presentation for `contains` over
alternatives

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

Re: Having a non-enumerable Array.prototype.contains may not be web-compatible

[Jason Orendorff]

On Tue, Sep 30, 2014 at 5:35 PM, Andrea Giammarchi
 wrote:
> I'm personally against unmaintained code and/or websites but here it's not
> ES7 breaking the web, it's a library already broken (somehow) due native
> prototype pollution without a mechanism to prevent these, apparently
> historically known, problems.

Either way, you're telling me I should ship a browser that chokes on
thousands of web sites that work fine today. That would be bad for our
users, so I'm not planning on doing that.

> it is also already patched and it's also a small fix.

The 6.5% of existing web sites using JS libraries that use MooTools
have not been "already patched". Patching 3.5 million web sites is not
a "small fix" in any relevant sense. It simply will not be done
thoroughly or soon.

> If sites and developers have no reason to update code 'cause ES7 cannot
> release until they'll change a file ... why would they anyway.

Yes. You have correctly identified incentives as a problem.

That does not constitute a reductio proof that browser vendors must
ignore their users' interests and break the web. "Reductio ad
the-world-is-not-as-I-wish-it-to-be" is not a thing.

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

Re: Having a non-enumerable Array.prototype.contains may not be web-compatible

[John-David Dalton]

> Did you ask them to fix their code so it doesn't fail for any name, not
just for 'contains'? Thanks,

I didn't, but will follow up with that.

JDD

On Tue, Sep 30, 2014 at 3:50 PM, Brendan Eich  wrote:

> John-David Dalton wrote:
>
>> Just a heads up, I've pinged MooTools core to inquire about fast-pathing
>> a patch release for Array#contains.
>>
>
> Did you ask them to fix their code so it doesn't fail for any name, not
> just for 'contains'? Thanks,
>
> /be
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Toplevel 'let' binding can be left permanently uninitialized after an error

[Brendan Eich]

David Herman wrote:

I'm usually less concerned about REPLs, since they can decide for themselves 
what kind of context they want to execute in -- or even invent new non-standard 
non-terminals, frankly -- although in this case it's not quite clear what a let 
declaration*should*  do in the REPL. Maybe developer consoles should actually 
treat `let` the way IMO we should've done for scripts.:)


Agree that nesting is a bad idea for 

Re: Having a non-enumerable Array.prototype.contains may not be web-compatible

[Brendan Eich]

John-David Dalton wrote:
Just a heads up, I've pinged MooTools core to inquire about 
fast-pathing a patch release for Array#contains.


Did you ask them to fix their code so it doesn't fail for any name, not 
just for 'contains'? Thanks,


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

Re: Having a non-enumerable Array.prototype.contains may not be web-compatible

[Andrea Giammarchi]

I'm personally against unmaintained code and/or websites but here it's not
ES7 breaking the web, it's a library already broken (somehow) due native
prototype pollution without a mechanism to prevent these, apparently
historically known, problems.

Should ES7 be planned around all methods already taken in there? I don't
think so + it is also already patched and it's also a small fix.

If sites and developers have no reason to update code 'cause ES7 cannot
release until they'll change a file ... why would they anyway.

Best Regards

On Tue, Sep 30, 2014 at 9:02 PM, Oliver Hunt  wrote:

> The problem is not people actively developing it, or creating new content
> with it.  The problem is _existing_ content that might break. All libraries
> have periods where they are in vogue, and then fade out leaving detritus
> that hangs around for years/decades on major sites.
>
> --Oliver
>
>
>
> On Sep 30, 2014, at 12:45 PM, Andrea Giammarchi <
> andrea.giammar...@gmail.com> wrote:
>
> "the current state of the web" ... with all due respect for that library,
> it's been years since I've heard anything about it.
>
> It's also common on the old web to loop over Arrays via `for/in` to avoid
> checks for sparse indexes through the entire length ... so making anything
> enumerable in that native prototype would break something else too form
> days where `getOwnPropertyNames` was unknown.
>
> long story short: I definitively +1 what Michał Wadas already said, it's
> already patched and people must update software anyway due security
> problems, **patches**, etc etc.
>
> just my .02
>
>
>
> On Tue, Sep 30, 2014 at 8:18 PM, Boris Zbarsky  wrote:
>
>> On 9/30/14, 2:45 PM, Michał Wadas wrote:
>>
>>> Bug in MooTools is not a reason to make any method of Array.prototype
>>> enumerable.
>>>
>>
>> I didn't say we need to make it enumerable.
>>
>> I said that given the current state of the web, a web browser cannot ship
>> a non-enumerable method named "contains" on Array.prototype.
>>
>> The options, therefore, are:
>>
>> 1)  Make the method enumerable.
>> 2)  Name the method something else.
>> 3)  Don't ship the method until every site that currently uses the
>> buggy versions of MooTools (which is every site that uses
>> MooTools, since they only fixed it 4 days ago).
>>
>> I'm perfectly fine with option 3, personally.  Note that in practice that
>> likely means "never ship it" unless people make some sort of concerted
>> effort to get sites to update their MooTools version.
>>
>> -Boris
>>
>> P.S. It may be worth avoiding the method names mootools sets up but
>> doesn't force-copy in the future.  Even better would be getting them to fix
>> their code so there are no such method names, of course.
>>
>> ___
>> 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
>
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Having a non-enumerable Array.prototype.contains may not be web-compatible

[John-David Dalton]

There is no need to change the name.
MooTools has had these issues in the past (they've broke with ES5, ES6, &
ES7 methods).
Array#contains is ES7 so there's time for their patch to release/propagate.

- JDD


On Tue, Sep 30, 2014 at 3:04 PM, Jason Orendorff 
wrote:

> On Tue, Sep 30, 2014 at 1:45 PM, Michał Wadas 
> wrote:
> > Bug in MooTools is not a reason to make any method of Array.prototype
> > enumerable.
>
> Well -- true, that would break even more sites.
>
> We're backing out Array#contains() for now. It's disappointing to me
> personally -- that was a volunteer contribution. In the long run,
> perhaps renaming it is the best course? :-\
>
> -j
> ___
> 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: Having a non-enumerable Array.prototype.contains may not be web-compatible

[Jason Orendorff]

On Tue, Sep 30, 2014 at 1:45 PM, Michał Wadas  wrote:
> Bug in MooTools is not a reason to make any method of Array.prototype
> enumerable.

Well -- true, that would break even more sites.

We're backing out Array#contains() for now. It's disappointing to me
personally -- that was a volunteer contribution. In the long run,
perhaps renaming it is the best course? :-\

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

Re: Toplevel 'let' binding can be left permanently uninitialized after an error

[Jason Orendorff]

On Tue, Sep 30, 2014 at 12:00 PM, Rick Waldron  wrote:
> My original response questions were poorly asked. I understand the TDZ
> semantics, but I couldn't reproduce anything meaningful from your original
> example, because I don't have the SpiderMonkey build that includes the let
> updates (presumably Nightly doesn't either, because none of these can be
> reproduced there).

SpiderMonkey doesn't conform to the draft spec yet. We implemented TDZ
in functions, but not at toplevel. 'const' isn't lexical yet. There's
a lot more work to do.

> I'm trying to understand when/where/why/how the original
> example could happen and what the potential consequences are in terms of
> practical application.

Purely hypothetical for us, for now. It came up on IRC. Some engineers
were discussing the breaking changes we're going to have to make.

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

Re: Having a non-enumerable Array.prototype.contains may not be web-compatible

[Boris Zbarsky]

On 9/30/14, 4:29 PM, Rick Waldron wrote:

This may be helpful:
http://trends.builtwith.com/javascript/javascript-library


Rick, thank you!

This says 1.32% on top 10k sites, 3.05% on top 100k sites, 4.78% on top 
million sites, and 6.39% overall.


There's definitely been a recent dip in those numbers, of course.  Used 
to be even higher.


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

Re: Having a non-enumerable Array.prototype.contains may not be web-compatible

[John-David Dalton]

Just a heads up, I've pinged MooTools core to inquire about fast-pathing a
patch release for Array#contains.

- JDD

On Tue, Sep 30, 2014 at 1:29 PM, Rick Waldron 
wrote:

>
>
> On Tue, Sep 30, 2014 at 4:16 PM, Boris Zbarsky  wrote:
>
>> On 9/30/14, 3:45 PM, Andrea Giammarchi wrote:
>>
>>> "the current state of the web" ... with all due respect for that
>>> library, it's been years since I've heard anything about it.
>>>
>>
>> "They have ears, but cannot hear..."
>>
>> This is a reasonably commonly used library, as libraries go.
>
>
>
> This may be helpful:
> http://trends.builtwith.com/javascript/javascript-library
>
> Rick
>
>
> ___
> 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: Toplevel 'let' binding can be left permanently uninitialized after an error

[David Herman]

On Sep 30, 2014, at 4:03 AM, Andreas Rossberg  wrote:

> On 30 September 2014 12:52, Jason Orendorff  wrote:
>> I just realized this has an unfortunate implication for REPLs. Suppose
>> you make this typo:
>> 
>>js> let x = Math.cso(a)// oops, TypeError, should be Math.cos
>> 
>> Now x is irreparably hosed in your REPL. That seems bad.
> 
> No surprise. One of the reasons why I always favoured a nested scopes
> model for multiple scripts...

We've had this debate a million times, but for anyone who's unfamiliar with the 
arguments: nested scopes makes recursive bindings across scripts impossible and 
is also hard to understand with things like asynchronous script execution order 
(such as 

Re: Having a non-enumerable Array.prototype.contains may not be web-compatible

[Rick Waldron]

On Tue, Sep 30, 2014 at 4:16 PM, Boris Zbarsky  wrote:

> On 9/30/14, 3:45 PM, Andrea Giammarchi wrote:
>
>> "the current state of the web" ... with all due respect for that
>> library, it's been years since I've heard anything about it.
>>
>
> "They have ears, but cannot hear..."
>
> This is a reasonably commonly used library, as libraries go.



This may be helpful:
http://trends.builtwith.com/javascript/javascript-library

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

Re: Having a non-enumerable Array.prototype.contains may not be web-compatible

[Boris Zbarsky]

On 9/30/14, 3:45 PM, Andrea Giammarchi wrote:

"the current state of the web" ... with all due respect for that
library, it's been years since I've heard anything about it.


"They have ears, but cannot hear..."

This is a reasonably commonly used library, as libraries go.

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

RE: Having a non-enumerable Array.prototype.contains may not be web-compatible

[Domenic Denicola]

Welp, nothing to do but add @@unMooToolsables.

From: Boris Zbarsky
Sent: ‎2014-‎09-‎30 19:21
To: es-discuss
Subject: Having a non-enumerable Array.prototype.contains may not be 
web-compatible

See https://bugzilla.mozilla.org/show_bug.cgi?id=1075059 for a case it
breaks, for example.

-Boris
___
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: Having a non-enumerable Array.prototype.contains may not be web-compatible

[Rick Waldron]

On Tue, Sep 30, 2014 at 4:02 PM, Oliver Hunt  wrote:

> The problem is not people actively developing it, or creating new content
> with it.  The problem is _existing_ content that might break. All libraries
> have periods where they are in vogue, and then fade out leaving detritus
> that hangs around for years/decades on major sites.
>

In these cases, evangelism over the next two years will help. Most major
sites are also maintained sites, which means there is time to work on
getting the necessary fixes implemented.

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

Re: Having a non-enumerable Array.prototype.contains may not be web-compatible

[Rick Waldron]

On Tue, Sep 30, 2014 at 3:45 PM, Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:

> "the current state of the web" ... with all due respect for that library,
> it's been years since I've heard anything about it.
>

Seconded—arguably MooTools' decline in usership is because of conflicts
such as this.

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

Re: Having a non-enumerable Array.prototype.contains may not be web-compatible

[Oliver Hunt]

The problem is not people actively developing it, or creating new content with 
it.  The problem is _existing_ content that might break. All libraries have 
periods where they are in vogue, and then fade out leaving detritus that hangs 
around for years/decades on major sites.

--Oliver


> On Sep 30, 2014, at 12:45 PM, Andrea Giammarchi  
> wrote:
> 
> "the current state of the web" ... with all due respect for that library, 
> it's been years since I've heard anything about it.
> 
> It's also common on the old web to loop over Arrays via `for/in` to avoid 
> checks for sparse indexes through the entire length ... so making anything 
> enumerable in that native prototype would break something else too form days 
> where `getOwnPropertyNames` was unknown.
> 
> long story short: I definitively +1 what Michał Wadas already said, it's 
> already patched and people must update software anyway due security problems, 
> **patches**, etc etc.
> 
> just my .02
> 
> 
> 
> On Tue, Sep 30, 2014 at 8:18 PM, Boris Zbarsky  > wrote:
> On 9/30/14, 2:45 PM, Michał Wadas wrote:
> Bug in MooTools is not a reason to make any method of Array.prototype
> enumerable.
> 
> I didn't say we need to make it enumerable.
> 
> I said that given the current state of the web, a web browser cannot ship a 
> non-enumerable method named "contains" on Array.prototype.
> 
> The options, therefore, are:
> 
> 1)  Make the method enumerable.
> 2)  Name the method something else.
> 3)  Don't ship the method until every site that currently uses the
> buggy versions of MooTools (which is every site that uses
> MooTools, since they only fixed it 4 days ago).
> 
> I'm perfectly fine with option 3, personally.  Note that in practice that 
> likely means "never ship it" unless people make some sort of concerted effort 
> to get sites to update their MooTools version.
> 
> -Boris
> 
> P.S. It may be worth avoiding the method names mootools sets up but doesn't 
> force-copy in the future.  Even better would be getting them to fix their 
> code so there are no such method names, of course.
> 
> ___
> 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

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

Re: Having a non-enumerable Array.prototype.contains may not be web-compatible

[John-David Dalton]

MooTools breaking because of additions/changes is not a new thing. It has
been broken in the past by things like Function#bind, String#contains, &
Moz removing document.getBoxObjectFor.
Its activity has slowed overall though there is an effort to re-energize
core contributions. Their core has put effort towards another project,
Prime, which does not augment native prototypes.

-JDD

On Tue, Sep 30, 2014 at 12:45 PM, Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:

> "the current state of the web" ... with all due respect for that library,
> it's been years since I've heard anything about it.
>
> It's also common on the old web to loop over Arrays via `for/in` to avoid
> checks for sparse indexes through the entire length ... so making anything
> enumerable in that native prototype would break something else too form
> days where `getOwnPropertyNames` was unknown.
>
> long story short: I definitively +1 what Michał Wadas already said, it's
> already patched and people must update software anyway due security
> problems, **patches**, etc etc.
>
> just my .02
>
>
>
> On Tue, Sep 30, 2014 at 8:18 PM, Boris Zbarsky  wrote:
>
>> On 9/30/14, 2:45 PM, Michał Wadas wrote:
>>
>>> Bug in MooTools is not a reason to make any method of Array.prototype
>>> enumerable.
>>>
>>
>> I didn't say we need to make it enumerable.
>>
>> I said that given the current state of the web, a web browser cannot ship
>> a non-enumerable method named "contains" on Array.prototype.
>>
>> The options, therefore, are:
>>
>> 1)  Make the method enumerable.
>> 2)  Name the method something else.
>> 3)  Don't ship the method until every site that currently uses the
>> buggy versions of MooTools (which is every site that uses
>> MooTools, since they only fixed it 4 days ago).
>>
>> I'm perfectly fine with option 3, personally.  Note that in practice that
>> likely means "never ship it" unless people make some sort of concerted
>> effort to get sites to update their MooTools version.
>>
>> -Boris
>>
>> P.S. It may be worth avoiding the method names mootools sets up but
>> doesn't force-copy in the future.  Even better would be getting them to fix
>> their code so there are no such method names, of course.
>>
>> ___
>> 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
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Having a non-enumerable Array.prototype.contains may not be web-compatible

[Andrea Giammarchi]

"the current state of the web" ... with all due respect for that library,
it's been years since I've heard anything about it.

It's also common on the old web to loop over Arrays via `for/in` to avoid
checks for sparse indexes through the entire length ... so making anything
enumerable in that native prototype would break something else too form
days where `getOwnPropertyNames` was unknown.

long story short: I definitively +1 what Michał Wadas already said, it's
already patched and people must update software anyway due security
problems, **patches**, etc etc.

just my .02



On Tue, Sep 30, 2014 at 8:18 PM, Boris Zbarsky  wrote:

> On 9/30/14, 2:45 PM, Michał Wadas wrote:
>
>> Bug in MooTools is not a reason to make any method of Array.prototype
>> enumerable.
>>
>
> I didn't say we need to make it enumerable.
>
> I said that given the current state of the web, a web browser cannot ship
> a non-enumerable method named "contains" on Array.prototype.
>
> The options, therefore, are:
>
> 1)  Make the method enumerable.
> 2)  Name the method something else.
> 3)  Don't ship the method until every site that currently uses the
> buggy versions of MooTools (which is every site that uses
> MooTools, since they only fixed it 4 days ago).
>
> I'm perfectly fine with option 3, personally.  Note that in practice that
> likely means "never ship it" unless people make some sort of concerted
> effort to get sites to update their MooTools version.
>
> -Boris
>
> P.S. It may be worth avoiding the method names mootools sets up but
> doesn't force-copy in the future.  Even better would be getting them to fix
> their code so there are no such method names, of course.
>
> ___
> 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: Having a non-enumerable Array.prototype.contains may not be web-compatible

[Boris Zbarsky]

On 9/30/14, 2:45 PM, Michał Wadas wrote:

Bug in MooTools is not a reason to make any method of Array.prototype
enumerable.


I didn't say we need to make it enumerable.

I said that given the current state of the web, a web browser cannot 
ship a non-enumerable method named "contains" on Array.prototype.


The options, therefore, are:

1)  Make the method enumerable.
2)  Name the method something else.
3)  Don't ship the method until every site that currently uses the
buggy versions of MooTools (which is every site that uses
MooTools, since they only fixed it 4 days ago).

I'm perfectly fine with option 3, personally.  Note that in practice 
that likely means "never ship it" unless people make some sort of 
concerted effort to get sites to update their MooTools version.


-Boris

P.S. It may be worth avoiding the method names mootools sets up but 
doesn't force-copy in the future.  Even better would be getting them to 
fix their code so there are no such method names, of course.

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

Re: Maximally minimal stack trace standardization

[Carl Smith]

Just to be clear, you can convert a stack trace into a struct pretty
easily, and then do source mapping on it with Mozilla Source Maps. This
already works. I can see why a console would provide integrated source map
support, but no reason for that to be exposed to client code. It's only a
rarely used, pure convenience outside of dev tools.

>From a humble Web dev's point of view, the important distinction is between
what I depend on the browser for, and what I can fix myself.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Maximally minimal stack trace standardization

[Carl Smith]

On 30 September 2014 17:28, John Lenz  wrote:

> I don't believe we want source map involved as, as you say, that
> information needs to be retrieved separately.
>
I seems there's three parts to this. One is allowing evals to be named the
way Chrome does, and providing line and column numbers for both caught and
uncaught errors. Another is improving the stack traces, providing an array
of hashes instead of a string. The last is source map support. I don't
personally see any reason to bundle this stuff into one issue.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Having a non-enumerable Array.prototype.contains may not be web-compatible

[Michał Wadas]

Bug in MooTools is not a reason to make any method of Array.prototype
enumerable.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Having a non-enumerable Array.prototype.contains may not be web-compatible

[Boris Zbarsky]

See https://bugzilla.mozilla.org/show_bug.cgi?id=1075059 for a case it 
breaks, for example.


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

Re: Toplevel 'let' binding can be left permanently uninitialized after an error

[Erik Arvidsson]

On Tue, Sep 30, 2014 at 2:08 PM, Brian Genisio 
wrote:

> FYI, you can also see this behavior in Node.js (v0.11.14)
>
> node --harmony --strict-mode
>

V8's support of let is far from spec compliant. Stuff under --harmony is
incomplete, buggy and may have security holes. Do not use!

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

Re: Toplevel 'let' binding can be left permanently uninitialized after an error

[Brian Genisio]

FYI, you can also see this behavior in Node.js (v0.11.14)

node --harmony --strict-mode

On Tue, Sep 30, 2014 at 1:24 PM, Rick Waldron 
wrote:

>
>
> On Tue, Sep 30, 2014 at 1:08 PM, Allen Wirfs-Brock 
> wrote:
>
>>
>> On Sep 30, 2014, at 10:00 AM, Rick Waldron wrote:
>>
>>
>> My original response questions were poorly asked. I understand the TDZ
>> semantics, but I couldn't reproduce anything meaningful from your original
>> example, because I don't have the SpiderMonkey build that includes the let
>> updates (presumably Nightly doesn't either, because none of these can be
>> reproduced there). I'm trying to understand when/where/why/how the original
>> example could happen and what the potential consequences are in terms of
>> practical application.
>>
>>
>> Also, note that IE11 apparently implements the ES6 let semantics so it
>> may be useful to look at its experience in this regard.
>>
>
> As a Mac user, I completely forgot about this. Using Browserstack.com, I
> was able to reproduce the original example's behavior by running a script
> and then attempting to access or assign to x from the console. The behavior
> I observe is exactly what I expect. I'm still unable to provide any further
> insight regarding Jason's original comments and practical implications of
> reported behavior.
>
>   "That by itself isn't necessarily a problem. I've never written a web
>   page where I wanted to recover after a toplevel script threw an
>   exception (or timed out)."
>
> I agree with the first assertion for the same reason stated.
>
> Rick
>
>
> ___
> 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: Toplevel 'let' binding can be left permanently uninitialized after an error

[Rick Waldron]

On Tue, Sep 30, 2014 at 1:08 PM, Allen Wirfs-Brock 
wrote:

>
> On Sep 30, 2014, at 10:00 AM, Rick Waldron wrote:
>
>
> My original response questions were poorly asked. I understand the TDZ
> semantics, but I couldn't reproduce anything meaningful from your original
> example, because I don't have the SpiderMonkey build that includes the let
> updates (presumably Nightly doesn't either, because none of these can be
> reproduced there). I'm trying to understand when/where/why/how the original
> example could happen and what the potential consequences are in terms of
> practical application.
>
>
> Also, note that IE11 apparently implements the ES6 let semantics so it may
> be useful to look at its experience in this regard.
>

As a Mac user, I completely forgot about this. Using Browserstack.com, I
was able to reproduce the original example's behavior by running a script
and then attempting to access or assign to x from the console. The behavior
I observe is exactly what I expect. I'm still unable to provide any further
insight regarding Jason's original comments and practical implications of
reported behavior.

  "That by itself isn't necessarily a problem. I've never written a web
  page where I wanted to recover after a toplevel script threw an
  exception (or timed out)."

I agree with the first assertion for the same reason stated.

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

Re: Toplevel 'let' binding can be left permanently uninitialized after an error

[Allen Wirfs-Brock]

On Sep 30, 2014, at 10:00 AM, Rick Waldron wrote:
> 
> My original response questions were poorly asked. I understand the TDZ 
> semantics, but I couldn't reproduce anything meaningful from your original 
> example, because I don't have the SpiderMonkey build that includes the let 
> updates (presumably Nightly doesn't either, because none of these can be 
> reproduced there). I'm trying to understand when/where/why/how the original 
> example could happen and what the potential consequences are in terms of 
> practical application.
> 

Also, note that IE11 apparently implements the ES6 let semantics so it may be 
useful to look at its experience in this regard.

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

Re: Toplevel 'let' binding can be left permanently uninitialized after an error

[Rick Waldron]

On Tue, Sep 30, 2014 at 6:38 AM, Jason Orendorff 
wrote:

> On Mon, Sep 29, 2014 at 4:14 PM, Rick Waldron 
> wrote:
> > Can you clarify "write"? Does this mean assignment?
>
> Yes.
>
> > Why would assignment throw?
>
> Assigning to an uninitialized variable is an error in ES6. A
> let-binding is initialized when its declaration is evaluated. So this
> is OK:
>
> let x;  // no Initializer, so it's initialized to undefined
> console.log(x);  // logs undefined
>
> but this is not:
>
> init();
> let answer;
> function init() {
> answer = 42;  // throws ReferenceError
> }
>

My original response questions were poorly asked. I understand the TDZ
semantics, but I couldn't reproduce anything meaningful from your original
example, because I don't have the SpiderMonkey build that includes the let
updates (presumably Nightly doesn't either, because none of these can be
reproduced there). I'm trying to understand when/where/why/how the original
example could happen and what the potential consequences are in terms of
practical application.


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

Re: Maximally minimal stack trace standardization

[John Lenz]

I don't believe we want source map involved as, as you say, that
information needs to be retrieved separately.
On Sep 30, 2014 5:17 AM, "Fitzgerald, Nick"  wrote:

>  On 9/30/14, 3:44 AM, John Lenz wrote:
>
> It is a defacto standard.
> On Sep 29, 2014 6:36 PM, "Brendan Eich"  wrote:
>
>> Carl Smith wrote:
>>
>>> If the source URL hack, or some cleaner wrapper for it, was
>>> standardised, it'd make all the difference.
>>>
>>
>> Why don't we just make the source URL hack a de-facto standard? That's
>> how evolution happens, in the best case. Cc'ing @fitzgen.
>>
>> /be
>>
>
> I remember web compat concerns, but if Chrome is exposing the `//#
> sourceURL` to the web in error stacks, maybe we can get away with it as
> well. I'd defer to jorendorff's opinion on this.
>
> We've also discussed exposing the source mapped location of stack frames
> to JS, but that's even trickier:
>
> * We don't do any source mapping unless devtools are open, so exposing
> this would leak whether the user is using devtools or not. Not sure how
> serious that is, but it makes me hesitant. On the other hand, always source
> mapping seems impractical, but maybe that's a false assumption.
>
> * It is a nonstarter to block JS on fetching a source map, so early stack
> traces would not be source mapped, while later ones would be. This sort of
> non-determinism makes me feel :( We could introduce a new async method for
> getting stacks and only source map for these async stacks (or make the new
> method that other branches of this thread are discussing async).
>
> Interested in hearing everyone's thoughts on this.
>
> Cheers,
>
> Nick
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Toplevel 'let' binding can be left permanently uninitialized after an error

[Mark S. Miller]

Likewise. E is also a scripting repl language with dynamic types and static
scopes. We tried a variety of different ways to handle the top level repl
and nested scopes were best.
On Sep 30, 2014 4:04 AM, "Andreas Rossberg"  wrote:

> On 30 September 2014 12:52, Jason Orendorff 
> wrote:
> > I just realized this has an unfortunate implication for REPLs. Suppose
> > you make this typo:
> >
> > js> let x = Math.cso(a)// oops, TypeError, should be Math.cos
> >
> > Now x is irreparably hosed in your REPL. That seems bad.
>
> No surprise. One of the reasons why I always favoured a nested scopes
> model for multiple scripts...
>
> /Andreas
> ___
> 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: Maximally minimal stack trace standardization

[Andreas Rossberg]

On 30 September 2014 16:31, Sam Tobin-Hochstadt  wrote:
> On Tue, Sep 30, 2014 at 6:56 AM, Andreas Rossberg  wrote:
>> On 29 September 2014 19:25, Brendan Eich  wrote:
>>> Mark S. Miller wrote:
 That's why, IIRC (haven't checked lately), TCO is only specified for calls
 from non-sloppy functions.
>>>
>>> PTC (Proper Tail Calls), not TCO. It's confusing to equate the two, from
>>> what I know (corrections welcome0.
>>
>> Hm, people most often refer to "mandatory tail call
>> optimisation/elimination" when talking about a spec level requirement.
>> I have never seen "PTC" used in a formal context, let alone the
>> acronym.
>
> Clinger's paper, which formalizes the concept, calls it "proper tail
> recursion" in the title, as does the R5RS Scheme standard. Since
> recursion isn't fundamental, though, proper tail calls seems more
> accurate. This terminology is used lots of places these days, such as
> the Lua docs and this (archive of a) post by Guy Steele:
> http://www.eighty-twenty.org/index.cgi/tech/oo-tail-calls-20111001.html

Interesting, good to know. Thanks for the clarification.

(Still wondering what improper tail calls would be.)

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

Re: Maximally minimal stack trace standardization

[Sam Tobin-Hochstadt]

On Tue, Sep 30, 2014 at 6:56 AM, Andreas Rossberg  wrote:
> On 29 September 2014 19:25, Brendan Eich  wrote:
>> Mark S. Miller wrote:
>>> That's why, IIRC (haven't checked lately), TCO is only specified for calls
>>> from non-sloppy functions.
>>
>> PTC (Proper Tail Calls), not TCO. It's confusing to equate the two, from
>> what I know (corrections welcome0.
>
> Hm, people most often refer to "mandatory tail call
> optimisation/elimination" when talking about a spec level requirement.
> I have never seen "PTC" used in a formal context, let alone the
> acronym.

Clinger's paper, which formalizes the concept, calls it "proper tail
recursion" in the title, as does the R5RS Scheme standard. Since
recursion isn't fundamental, though, proper tail calls seems more
accurate. This terminology is used lots of places these days, such as
the Lua docs and this (archive of a) post by Guy Steele:
http://www.eighty-twenty.org/index.cgi/tech/oo-tail-calls-20111001.html

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

Re: Maximally minimal stack trace standardization

[Nick Fitzgerald]

I remember web compat concerns, but if Chrome is exposing the `//#
sourceURL` to the web in error stacks, maybe we can get away with it
as well. I'd defer to jorendorff's opinion on this.

We've also discussed exposing the source mapped location of stack
frames to JS, but that's even trickier:

* We don't do any source mapping unless devtools are open, so exposing
this would leak whether the user is using devtools or not. Not sure
how serious that is, but it makes me hesitant. On the other hand,
always source mapping seems impractical, but maybe that's a false
assumption.

* It is a nonstarter to block JS on fetching a source map, so early
stack traces would not be source mapped, while later ones would be.
This sort of non-determinism makes me feel :( We could introduce a new
async method for getting stacks and only source map for these async
stacks (or make the new method that other branches of this thread are
discussing async).

Interested in hearing everyone's thoughts on this.

Cheers,

_Nick_


On Tue, Sep 30, 2014 at 3:44 AM, John Lenz  wrote:
> It is a defacto standard.
>
> On Sep 29, 2014 6:36 PM, "Brendan Eich"  wrote:
>>
>> Carl Smith wrote:
>>>
>>> If the source URL hack, or some cleaner wrapper for it, was standardised,
>>> it'd make all the difference.
>>
>>
>> Why don't we just make the source URL hack a de-facto standard? That's how
>> evolution happens, in the best case. Cc'ing @fitzgen.
>>
>> /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: Maximally minimal stack trace standardization

[Carl Smith]

John Lenz, using source URLs for naming eval'ed code in the traceback
provided to `window.onerror` isn't a de-facto standard; only V8 does it??
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Toplevel 'let' binding can be left permanently uninitialized after an error

[Andreas Rossberg]

On 30 September 2014 12:52, Jason Orendorff  wrote:
> I just realized this has an unfortunate implication for REPLs. Suppose
> you make this typo:
>
> js> let x = Math.cso(a)// oops, TypeError, should be Math.cos
>
> Now x is irreparably hosed in your REPL. That seems bad.

No surprise. One of the reasons why I always favoured a nested scopes
model for multiple scripts...

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

Re: Maximally minimal stack trace standardization

[Andreas Rossberg]

Boris' point seems to be -- and I agree -- that such a test would only
be a semi-decision procedure. I.e., it can only falsify, but not
validate the property for the test program.

/Andreas


On 30 September 2014 04:48, Brendan Eich  wrote:
> Put it in a worker or node.js. The point Sam was making was based on 
> Ecma-262, no browser watchdog required.
>
> /be
>
>> On Sep 29, 2014, at 6:47 PM, Boris Zbarsky  wrote:
>>
>>> On 9/29/14, 4:16 PM, Sam Tobin-Hochstadt wrote:
>>> We'd consider it a spec violation (at least, I would), if this program
>>> ran out of space, ever:
>>>
>>> var i = 0;
>>> while (1) {  i++; };
>>
>> How would you know whether it does?  You can't tell whether your program is 
>> terminated because it runs out of space or because the browser has decided 
>> it's hung and killed it
>>
>> -Boris
>> ___
>> 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
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Maximally minimal stack trace standardization

[Andreas Rossberg]

On 29 September 2014 19:25, Brendan Eich  wrote:
> Mark S. Miller wrote:
>> That's why, IIRC (haven't checked lately), TCO is only specified for calls
>> from non-sloppy functions.
>
> PTC (Proper Tail Calls), not TCO. It's confusing to equate the two, from
> what I know (corrections welcome0.

Hm, people most often refer to "mandatory tail call
optimisation/elimination" when talking about a spec level requirement.
I have never seen "PTC" used in a formal context, let alone the
acronym.

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

Re: Event loops in navigated-away-from windows

[David Bruant]

Le 29/09/2014 23:08, Anne van Kesteren a écrit :

On Mon, Sep 29, 2014 at 8:18 PM, Ian Hickson  wrote:

I certainly wouldn't object to the ES spec's event loop algorithms being
turned inside out (search for "RunCode" on the esdiscuss thread above for
an e-mail where I propose this) but that would be purely an editorial
change, it wouldn't change the implementations.

The proposed setup from Allen will start failing the moment ECMAScript
wants something more complicated with its loop.

How likely is this?

David


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

Re: Toplevel 'let' binding can be left permanently uninitialized after an error

[Jason Orendorff]

I just realized this has an unfortunate implication for REPLs. Suppose
you make this typo:

js> let x = Math.cso(a)// oops, TypeError, should be Math.cos

Now x is irreparably hosed in your REPL. That seems bad.

I guess we can fix this by making the REPL bend the rules of the
language. But this is rather hard to do for REPLs implemented in JS.
Maybe the rules should just be a little more forgiving.

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

Re: Toplevel 'let' binding can be left permanently uninitialized after an error

[Jason Orendorff]

On Mon, Sep 29, 2014 at 4:14 PM, Rick Waldron  wrote:
> Can you clarify "write"? Does this mean assignment?

Yes.

> Why would assignment throw?

Assigning to an uninitialized variable is an error in ES6. A
let-binding is initialized when its declaration is evaluated. So this
is OK:

let x;  // no Initializer, so it's initialized to undefined
console.log(x);  // logs undefined

but this is not:

init();
let answer;
function init() {
answer = 42;  // throws ReferenceError
}

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