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

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 behavi

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

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

Re: Changing behavior of Array#copyWithin when used on array-like with negative length

Would "an array-like with a negative length field" read better in ecmaspeak? I'm talking about the value *before* ToLength is invoked. `Array.prototype.slice.call(3)` and `Array.prototype.slice.call({length:-1})` both complete successfully (and return the same value), due to the soothing effect of

Re: Changing behavior of Array#copyWithin when used on array-like with negative length

> Le 14 févr. 2014 à 23:40, "C. Scott Ananian" a écrit : > > Claude Pache wrote: >> "Array-likes with negative length" doesn't make sense. > > `Array.prototype.copyWithin.call({ length: -1 }, ... );` > > Call it whatever you like, although I'm always interested in learning > new phrases of EC

Re: System.import FTW

I don't think the details in System will be important, as you suggest there is not much to say. The critical issue is whether we will have access to an ES6 specified Loader class. The Loader class and System.fetch is enough I think to do any custom loader thing one wants. If we only have System the

Re: System.import FTW

On Fri, Feb 14, 2014 at 12:59 PM, David Herman wrote: > https://github.com/rwaldron/tc39-notes/blob/9ac398908394f9e2f8a1ac9b1e0c83952cd2f2fa/es6/2014-01/jan-28.md#spec-status-update Yeah, I read that, and I thought the absence of a 'Resolution' was a bit suspicious. I thought there was a strong

Re: System.import FTW

On Feb 14, 2014, at 12:09 PM, John Barton wrote: > (There is no spec on "System", just rumors that it will be a predefined, > global instance of Loader). "Rumors" is a bit much. :) The notes do show the discussion but the resolution for some reason didn't get recorded. IIRC there was agreement

Re: System.import FTW

On Feb 14, 2014, at 12:32 PM, C. Scott Ananian wrote: > john: yes, I suspected that System was underspecified. That's too bad. It's a separation of responsibilities. `System` is the point where the ECMAScript language (core module system) meets the host environment (filesystem/web browsers/et

Re: Promise.cast and Promise.resolve

On Fri, Feb 14, 2014 at 6:21 AM, Anne van Kesteren wrote: > To be clear, we fixed this. And we will be going ahead and shipping > promises in Firefox 29. Too many dependencies at this point to hold of > longer. Since both Chrome and FIrefox have plans to support Promises, feel free to suggest any

Re: Changing behavior of Array#copyWithin when used on array-like with negative length

On Fri, Feb 14, 2014 at 11:50 AM, André Bargull wrote: > I think Scott is requesting this change: > https://gist.github.com/anba/6c75c34c72d4ffaa8de7 Yes, although my proposed diff (in the linked bug) was the shorter, "12. If end is undefined, let relativeEnd be ToInteger(lenVal); else let relati

Re: Changing behavior of Array#copyWithin when used on array-like with negative length

> Le 14 févr. 2014 à 21:46, "C. Scott Ananian" a écrit : > > array-likes with negative length "Array-likes with negative length" doesn't make sense, or at least it isn't a useful concept as far as ECMAScript is concerned – as it doesn't make sense to consider arraylikes of fractional length,

Re: Changing behavior of Array#copyWithin when used on array-like with negative length

On Feb 14, 2014, at 12:46 PM, C. Scott Ananian wrote: >/ For reference:https://bugs.ecmascript.org/show_bug.cgi?id=2546 />/ />/ `Array#copyWithin` has a (non-normative) signature of `(target, start, />/ end = this.length)`. However, this is slightly misleading because the />/ spec actuall

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

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

Re: Changing behavior of Array#copyWithin when used on array-like with negative length

On Feb 14, 2014, at 12:46 PM, C. Scott Ananian wrote: > For reference: https://bugs.ecmascript.org/show_bug.cgi?id=2546 > > `Array#copyWithin` has a (non-normative) signature of `(target, start, > end = this.length)`. However, this is slightly misleading because the > spec actually calls `ToLen

Changing behavior of Array#copyWithin when used on array-like with negative length

For reference: https://bugs.ecmascript.org/show_bug.cgi?id=2546 `Array#copyWithin` has a (non-normative) signature of `(target, start, end = this.length)`. However, this is slightly misleading because the spec actually calls `ToLength` on `this.length` and then uses *that* for the default value o

Re: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`)

yes, of course. es6-shim is a large-ish collection of such. However, it would be much better to use an implementation of `String#at` which used substr and thus avoided creating and appending a new string object. --scott ___ es-discuss mailing list es-d

Re: System.import FTW

erik: I'd be interested in learning the outcome of the normalization discussion. As one of the maintainers of es6-shim I'm particularly interested in ways to access ES6 features with ES5 syntax. If that looks like: ```js this['default'] = Promise.join(System.import('foo'), System.import('bar'))

Re: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`)

On Fri, Feb 14, 2014 at 12:23 PM, C. Scott Ananian wrote: > I'm excited to start working on es7-shim once we get to that point! > (String.prototype.at has a particularly simple shim, thankfully...) > Have you seen: https://github.com/mathiasbynens/String.prototype.at ? Rick

Re: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`)

I'm excited to start working on es7-shim once we get to that point! (String.prototype.at has a particularly simple shim, thankfully...) --scott ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: System.import FTW

(There is no spec on "System", just rumors that it will be a predefined, global instance of Loader). As far I know the only way to use the es6 module loader without exports or imports is to set values on 'this', the global object. I guess it's not very different from using IIFE (function() { this.

Re: System.import FTW

On Fri Feb 14 2014 at 2:20:07 PM, C. Scott Ananian wrote: > Thanks. I was missing the relationship between System and Loader somehow. > > So System.import is intended to be exactly the same as the import keyword > (except promise-returning). > There is a big difference here. The syntax for import

Re: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`)

On Fri, Feb 14, 2014 at 10:59 AM, Allen Wirfs-Brock wrote: > On Feb 14, 2014, at 1:34 AM, Mathias Bynens wrote: > > > Allen mentioned that `String#at` might not make it to ES6 because nobody > in TC39 is championing it. I've now asked Rick if he would be the champion > for this, and he agreed. (Th

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

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 facto

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

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

Re: System.import FTW

Thanks. I was missing the relationship between System and Loader somehow. So System.import is intended to be exactly the same as the import keyword (except promise-returning). That's good! Is there a way to do without the export keyword as well (I've heard rumors of "anonymous exports" but haven'

Re: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`)

On Feb 14, 2014, at 1:34 AM, Mathias Bynens wrote: > Allen mentioned that `String#at` might not make it to ES6 because nobody in > TC39 is championing it. I’ve now asked Rick if he would be the champion for > this, and he agreed. (Thanks again!) > > Looking over the ‘TC39 progress’ document at

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

> 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

Re: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`)

On Fri, Feb 14, 2014 at 1:34 AM, Mathias Bynens wrote: > Allen mentioned that `String#at` might not make it to ES6 because nobody > in TC39 is championing it. I've now asked Rick if he would be the champion > for this, and he agreed. (Thanks again!) > Published to wiki here: http://wiki.ecmascri

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

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

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

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

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

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 E

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

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

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

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

Re: Promise.cast and Promise.resolve

On Fri, Feb 7, 2014 at 11:50 AM, Anne van Kesteren wrote: > I filed https://bugzilla.mozilla.org/show_bug.cgi?id=966348 on Gecko > when the news broke. Mozilla can probably still make things in order > before promises hit stable. To be clear, we fixed this. And we will be going ahead and shipping

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

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 rathe

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

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 ev

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

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;

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

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 wil

Re: restrictions on let declarations

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

Re: restrictions on let declarations

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) { ... }" >>

Re: System.import FTW

On 14 February 2014 14:13, C. Scott Ananian wrote: > Can someone point me to the spec for `System.import`? > It's in the ES6 specification draft under Loader.prototype.import - https://people.mozilla.org/~jorendorff/es6-draft.html#sec-loader.prototype.import . > > https://github.com/jorendorff

System.import FTW

Can someone point me to the spec for `System.import`? https://github.com/jorendorff/js-loaders/blob/master/browser-loader.js doesn't seem to include it. It seems to me that it would be worthwhile to ensure that `System.import` had good semantics. It would allow a nice migration path for existing

Re: MonadicPromises, revisited

My goal was simply to see how feasible it was to write a "autoboxing" Promise subclass that could be used for async maps, the Service Worker API, etc. It turns out that the subclass is quite small and straightforward, although Promise.all() and Promise.race() won't work as-is on these "monadic" pr

RE: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`)

I think Mathias's point, that it is exactly as useful or useless as `codePointAt`, is a reasonable one. However, > This method is just as useful as `String.prototype.codePointAt`. If that > method is included, so should `String.prototype.at`. If `String.prototype.at` > is found not to be useful

Re: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`)

Yes, I know what `String#at` is supposed to do. I was pointing out that `String#at` makes it easy to do the wrong thing. If you do `Array.from(str)` then you suddenly have a complete random-access data structure where you can find out the number of code points in the String, iterate it in reverse

Re: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`)

On 14 Feb 2014, at 11:14, C. Scott Ananian wrote: > Note that `Array.from(str)` and `str[Symbol.iterator]` overlap > significantly. In particular, it's somewhat awkward to iterate over > code points using `String#symbolAt`; it's much easier to use > `substr()` and then use the StringIterator. `

Re: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`)

On 14 Feb 2014, at 11:11, Domenic Denicola wrote: > This was the method that was only useful if you pass `0` to it? I’ll just avoid the infinite loop here by pointing to earlier posts in this thread where this was discussed before:

Re: MonadicPromises, revisited

On 14 February 2014 00:32, C. Scott Ananian wrote: > For your consideration, here is an implementation of Monadic Promises, > as a Promise subclass: Since promises are expressible in JS you can always create a new class that does what you want. It's also well-understood that you can do that using

Re: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`)

Note that `Array.from(str)` and `str[Symbol.iterator]` overlap significantly. In particular, it's somewhat awkward to iterate over code points using `String#symbolAt`; it's much easier to use `substr()` and then use the StringIterator. --scott ps. I see that Domenic has said something similar.

RE: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`)

This was the method that was only useful if you pass `0` to it? -Original Message- From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Mathias Bynens Sent: Friday, February 14, 2014 10:34 To: Rick Waldron; Allen Wirfs-Brock Cc: es-discuss@mozilla.org list Subject: Re: `S

Re: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`)

Allen mentioned that `String#at` might not make it to ES6 because nobody in TC39 is championing it. I’ve now asked Rick if he would be the champion for this, and he agreed. (Thanks again!) Looking over the ‘TC39 progress’ document at