I think you understood it right... But while the hard to implement argument is now invalid at least for SpiderMonkey, it's a really bad idea to add this to the language.<br><br>First of all, you read the blogpost, right? I explained pretty much how it makes *everything* unpredictable and volatile even. Having something like this would be a showstopper for having any serious logic done in JavaScript. You can't do anything that makes a critical state unstable without taking serious precautions and even then you might end up losing the whole state. This is even worse than putting&enforcing locks and mutexes in JS.<br>
<br>Second, it doesn't add any real value. If you take any real example where something like a wait keyword would make the code easier to read, let's say node.js only had an async readFile function:<br><br>var content<br>
<br>fs.readFile('blah.txt', function (e, data) {<br>  if (e) throw e<br><br>  content = data<br>}, 'utf8')<br><br>wait<br><br>// Do something with content<br><br>Here the wait will do *nothing*, because the callback isn't immediate, except in very rare edge cases maybe, and the content will be undefined when you start trying to process it.<br>
<br>So, while I still think it might be a prolific choice for browser vendors to do this in the main thread for blocking operations, as it will make everything go smoother regardless of a few bad eggs, and hardly anything breaks, I don't think it should be provided elsewhere and especially not as a language feature. And this is just my $0.02 (re: prolific choice), I think browser vendors will disagree with my view there, but what they'll most certainly agree with me on is that it's problematic to allow any kind of blocking operations in the main thread (especially timing-critical), and having alert(), confirm() and syncXHR in the first place was not a very good choice in hindsight. That's why I didn't believe it was a bug in the first place, seemed too designed.<br>
<br>Cheers,<br>Jussi<br><br><div class="gmail_quote">On Fri, Jul 6, 2012 at 12:03 PM, Patrik Stutz <span dir="ltr"><<a href="mailto:patrik.stutz@gmail.com" target="_blank">patrik.stutz@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><font color="#000000"><font><font face="verdana,sans-serif">Just to be sure I understood that thing right.</font></font></font><div>
<font face="verdana, sans-serif"><br></font></div><div><font face="verdana, sans-serif">When this is the "stack" of the example by </font><span style="font-family:arial,helvetica,sans-serif">Jussi Kalliokoski (other colors mean other queue entry)</span><div>

<div><ul><li><span style="font-family:verdana,sans-serif"><font color="#ff0000">console.log("1");</font></span></li><li><font color="#ff0000" face="verdana, sans-serif">console.log("2");</font></li><li>

<font color="#ff0000" face="verdana, sans-serif">wait;</font></li><li><font color="#ff0000" face="verdana, sans-serif">console.log("5");</font></li><li><font color="#ff9900" face="verdana, sans-serif">console.log("3");</font></li>

<li><font color="#3366ff" face="verdana, sans-serif">console.log("4");</font></li></ul><div><font face="verdana, sans-serif">The wait keyword made it execute this way:</font></div><div><ul><li><span style="font-family:verdana,sans-serif"><font color="#ff0000">console.log("1");</font></span></li>

<li><font color="#ff0000" face="verdana, sans-serif">console.log("2");</font></li><ul><li><span style="color:rgb(255,153,0);font-family:verdana,sans-serif">console.log("3");</span></li><li><span style="color:rgb(51,102,255);font-family:verdana,sans-serif">console.log("4");</span></li>

</ul><li><font color="#ff0000" face="verdana, sans-serif">console.log("5");</font></li></ul><div><font face="verdana, sans-serif">Instead of this way:</font></div></div><div><ul><li><span style="font-family:verdana,sans-serif"><font color="#ff0000">console.log("1");</font></span></li>

<li><font color="#ff0000" face="verdana, sans-serif">console.log("2");</font></li><li><span style="color:rgb(255,153,0);font-family:verdana,sans-serif">console.log("3");</span></li><li><span style="color:rgb(51,102,255);font-family:verdana,sans-serif">console.log("4");</span></li>

<li><font color="#33cc00" face="verdana, sans-serif">console.log("5");</font></li></ul><div><font face="verdana, sans-serif">?</font></div></div><div><font face="verdana, sans-serif"><br></font></div><div><font face="verdana, sans-serif">Ok, that's not how I suggested it to work. But to be honest, I think this approach is event better!</font></div>

<div><font face="verdana, sans-serif">You would'nt have to implement stack pausing/resuming at all! In fact, the "wait" or "delay" keyword would just create a new queue, move all entries from the main queue to that sub-queue and then run the queue blocking to its end. It all would just look like a normal function call and wouldn't be that hard to implement at all.</font></div>

<div><font face="verdana, sans-serif"><br></font></div><div><font face="verdana, sans-serif">You say that's a bug and this will indeed be right, but what about adding such a functionality to the spec?</font></div><div>

<font face="verdana, sans-serif">I think the argument about "to hard to implement" would be gone this way, right?</font></div><div><font face="verdana, sans-serif"><br></font></div><div><font face="verdana, sans-serif"><br>

</font></div><div><font color="#3366ff" face="verdana, sans-serif"><br></font></div></div><div><font color="#000000"><font><font face="verdana,sans-serif"><br></font></font></font><br><div class="gmail_quote">2012/7/6  <span dir="ltr"><<a href="mailto:es-discuss-request@mozilla.org" target="_blank">es-discuss-request@mozilla.org</a>></span><br>


<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Send es-discuss mailing list submissions to<br>
        <a href="mailto:es-discuss@mozilla.org" target="_blank">es-discuss@mozilla.org</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
        <a href="https://mail.mozilla.org/listinfo/es-discuss" target="_blank">https://mail.mozilla.org/listinfo/es-discuss</a><br>
or, via email, send a message with subject or body 'help' to<br>
        <a href="mailto:es-discuss-request@mozilla.org" target="_blank">es-discuss-request@mozilla.org</a><br>
<br>
You can reach the person managing the list at<br>
        <a href="mailto:es-discuss-owner@mozilla.org" target="_blank">es-discuss-owner@mozilla.org</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of es-discuss digest..."<br>
<br>Today's Topics:<br>
<br>
   1. Re: for-of statement of sparse array (Jason Orendorff)<br>
   2. Re: Static Module Resolution (Aymeric Vitte)<br>
   3. Re: for-of statement of sparse array (Brendan Eich)<br>
   4. Re: for-of statement of sparse array (Brendan Eich)<br>
   5. Re: Static Module Resolution (Brendan Eich)<br>
   6. Re: for-of statement of sparse array (Brendan Eich)<br>
   7. Re: for-of statement of sparse array (Rick Waldron)<br>
   8. Re: Fwd: "delay" keyword (Brendan Eich)<br>
<br><br>---------- Weitergeleitete Nachricht ----------<br>From: Jason Orendorff <<a href="mailto:jason.orendorff@gmail.com" target="_blank">jason.orendorff@gmail.com</a>><br>To: Allen Wirfs-Brock <<a href="mailto:allen@wirfs-brock.com" target="_blank">allen@wirfs-brock.com</a>><br>


Cc: Brendan Eich <<a href="mailto:brendan@mozilla.org" target="_blank">brendan@mozilla.org</a>>, ES-Discuss <<a href="mailto:es-discuss@mozilla.org" target="_blank">es-discuss@mozilla.org</a>><br>Date: Thu, 5 Jul 2012 18:10:29 -0500<br>

Subject: Re: for-of statement of sparse array<br>
On Thu, Jul 5, 2012 at 2:09 PM, Allen Wirfs-Brock <<a href="mailto:allen@wirfs-brock.com" target="_blank">allen@wirfs-brock.com</a>> wrote:<br>
>> Map may win at some point, who knows? It's not winning if one wants an array, numeric indexing, .length, the usual prototype methods.<br>
><br>
> We could consider also have "dense" interators available:<br>
><br>
>      for (let v of array.denseValues) console.log(v);<br>
<br>
This makes sense to me, but most arrays are meant to be dense in<br>
practice. So perhaps it makes more sense to add methods specifically<br>
for sparse arrays, making developers type more characters in the rare<br>
case rather than the common case:<br>
<br>
    for (let v of array.sparseValues()) ...;<br>
    for (let [i, v] of array.sparseItems()) ...;<br>
<br>
-j<br>
<br>
<br><br>---------- Weitergeleitete Nachricht ----------<br>From: Aymeric Vitte <<a href="mailto:vitteaymeric@gmail.com" target="_blank">vitteaymeric@gmail.com</a>><br>To: Sam Tobin-Hochstadt <<a href="mailto:samth@ccs.neu.edu" target="_blank">samth@ccs.neu.edu</a>><br>


Cc: Brendan Eich <<a href="mailto:brendan@mozilla.org" target="_blank">brendan@mozilla.org</a>>, "<a href="mailto:es-discuss@mozilla.org" target="_blank">es-discuss@mozilla.org</a>" <<a href="mailto:es-discuss@mozilla.org" target="_blank">es-discuss@mozilla.org</a>><br>


Date: Fri, 06 Jul 2012 01:15:09 +0200<br>Subject: Re: Static Module Resolution<br><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I don't understand your comment about `window` and `document`.  They<br>
are already globals in browser JS environments.<br>
</blockquote>
Please, take some time to read again my previous posts, I am refering to both server side's and browser's env, with 'window' and 'document' that are familiar as examples, but these could be 'mylocalvar1' and 'mylocalvar2' in both (and in my server side examples 'window' and 'document' are not supposed at all to be in fine globals)<br>



<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
As for async, there are a variety of ways to make it easier<br>
</blockquote>
No, the only way to ease your life is to define a lot of things as globals which some people like myself might not want to do, same as var script_=document.<u></u>createElement('script') callbacks, modules are reproducing the same<br>



<br>
I don't know if you develop everyday async code handling multiple asyncs stuff but it becomes all the time very quickly a nightmare<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
, but we<br>
are *not* going to add synchronous IO as part of the module system.<br>
The run-to-completion semantics of JS are non-negotiable.<br>
</blockquote>
Then the sync xhr is absurd ?<br>
<br>
The "non-negotiable" word reminds me some famous vendor not implementing the sync xhr for obscure purposes (not blocking the app or something like this), I did not check since that time but I would bet they finally implemented it<br>



<br>
It is really needed and looks so simple, do we have to live forever with the xhr limitations or can this simple thing be included ? (I understand it does not follow the global logic of modules/loaders but there might be a way)<br>



<br>
-- <br>
jCore<br>
Email :  <a href="mailto:avitte@jcore.fr" target="_blank">avitte@jcore.fr</a><br>
Web :    <a href="http://www.jcore.fr" target="_blank">www.jcore.fr</a><br>
Webble : <a href="http://www.webble.it" target="_blank">www.webble.it</a><br>
Extract Widget Mobile : <a href="http://www.extractwidget.com" target="_blank">www.extractwidget.com</a><br>
BlimpMe! : <a href="http://www.blimpme.com" target="_blank">www.blimpme.com</a><br>
<br>
<br>
<br>
<br>
<br><br>---------- Weitergeleitete Nachricht ----------<br>From: Brendan Eich <<a href="mailto:brendan@mozilla.org" target="_blank">brendan@mozilla.org</a>><br>To: Jason Orendorff <<a href="mailto:jason.orendorff@gmail.com" target="_blank">jason.orendorff@gmail.com</a>><br>


Cc: ES-Discuss <<a href="mailto:es-discuss@mozilla.org" target="_blank">es-discuss@mozilla.org</a>><br>Date: Thu, 05 Jul 2012 18:12:22 -0700<br>Subject: Re: for-of statement of sparse array<br>Jason Orendorff wrote:<br>


<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Thu, Jul 5, 2012 at 12:54 PM, Brendan Eich<<a href="mailto:brendan@mozilla.org" target="_blank">brendan@mozilla.org</a>>  wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Allen privately observed that Array forEach skips holes, matching for-in.<br>
That counts for a lot with me -- we have only a blind<br>
for(i=0;i<a.length;i++)... loop not skipping holes, but of course it<br>
wouldn't. That is weak precedent on which to build for-of.<br>
</blockquote>
<br>
In what sense is that precedent weak? It seems a stronger precedent<br>
than forEach on every axis; arguably it's one of the most-trodden<br>
cowpaths in programming, in any language.<br>
</blockquote>
<br>
That's too general a claim to be self-certifying. I <3 C but in JS, lots of a.forEach(function (e) {...}) usage these days. Kids are into FP.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
for-in is a kind of anti-precedent, for array iteration.<br>
</blockquote>
<br>
The point is for-in *in addition to* forEach and other Array extras skip holes. Not for-in by itself as motivation, really, just consistency of all but for-of as implemented.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Map may win at some point, who knows? It's not winning if one wants<br>
an array, numeric indexing, .length, the usual prototype methods.<br>
</blockquote>
<br>
I agree Map is somewhat beside the point. TC39 should spec what's best<br>
for developers net of everything. Even if that's matching for-in. But<br>
the purpose of for-of is to address the shortcomings of for-in;<br>
following it just for the sake of consistency would be self-defeating.<br>
</blockquote>
<br>
I think your focus is pulled by for-in too much. It happens to match the Array extras and this makes a happy consistency, but the main precedent is forEach, along with the rest of the extras which agree on skipping holes.<br>



<br>
If there's a botch here, it is holes in arrays, or rather: arrays not being like Python lists, instead being barely-specialized objects-with-properties. But that's a done deal. From that, holes follow.<br>
<br>
>From holes, skipping or not skipping consistently must follow. So far we've been consistent over the many years: for-in, forEach, etc. all skip.<br>
<br>
The C-style loop is blind to property existence so is really a different animal. It's true people are told not to use for-in on arrays, but that does not make them use for(;;). Instead they seem to reach for forEach. Which skips holes.<br>



<br>
Reasoning about latent bugs due to skipping holes is perilous and wants empirical studies, some evidence, a few burning anecdotes. Got any?<br>
<br>
/be<br>
<br>
<br><br>---------- Weitergeleitete Nachricht ----------<br>From: Brendan Eich <<a href="mailto:brendan@mozilla.org" target="_blank">brendan@mozilla.org</a>><br>To: Jason Orendorff <<a href="mailto:jason.orendorff@gmail.com" target="_blank">jason.orendorff@gmail.com</a>><br>


Cc: ES-Discuss <<a href="mailto:es-discuss@mozilla.org" target="_blank">es-discuss@mozilla.org</a>><br>Date: Thu, 05 Jul 2012 18:15:50 -0700<br>Subject: Re: for-of statement of sparse array<br>Jason Orendorff wrote:<br>


<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Thu, Jul 5, 2012 at 2:09 PM, Allen Wirfs-Brock<<a href="mailto:allen@wirfs-brock.com" target="_blank">allen@wirfs-brock.<u></u>com</a>>  wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Map may win at some point, who knows? It's not winning if one wants an array, numeric indexing, .length, the usual prototype methods.<br>
</blockquote>
We could consider also have "dense" interators available:<br>
<br>
      for (let v of array.denseValues) console.log(v);<br>
</blockquote>
<br>
This makes sense to me, but most arrays are meant to be dense in<br>
practice. So perhaps it makes more sense to add methods specifically<br>
for sparse arrays, making developers type more characters in the rare<br>
case rather than the common case:<br>
<br>
     for (let v of array.sparseValues()) ...;<br>
     for (let [i, v] of array.sparseItems()) ...;<br>
</blockquote>
<br>
No, this is human-hostile. Programmers don't generally make holes on purpose. You're right that accidental holes may mean bugs, but not necessarily -- especially if skipped. It's unclear and (I agree) messy, but given holes and 1JS compatibility, we can't really change the main iteration facilities used predominantly on arrays, and also used generically on all objects including arrays, to skip holes.<br>



<br>
The JSFixed request for Object.prototype.forEach wants nothing like for(i=0;i<a.length;i++), when used on an Array instance. It must skip holes. This upholes the Array forEach (and all other extras) hole-skipping. The deck is stacked against for(;;) iteration in my view.<br>



<br>
But to get back to your suggestion, that does not mean programmers think about sparse arrays usefully or specifically. They want generic iteration; they do not want holes to be iterated. At least, based on my experience and what I see others writing.<br>



<br>
/be<br>
<br>
<br><br>---------- Weitergeleitete Nachricht ----------<br>From: Brendan Eich <<a href="mailto:brendan@mozilla.org" target="_blank">brendan@mozilla.org</a>><br>To: Aymeric Vitte <<a href="mailto:vitteaymeric@gmail.com" target="_blank">vitteaymeric@gmail.com</a>><br>


Cc: "<a href="mailto:es-discuss@mozilla.org" target="_blank">es-discuss@mozilla.org</a>" <<a href="mailto:es-discuss@mozilla.org" target="_blank">es-discuss@mozilla.org</a>><br>Date: Thu, 05 Jul 2012 18:17:06 -0700<br>

Subject: Re: Static Module Resolution<br>
Aymeric Vitte wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Then the sync xhr is absurd ? <br>
</blockquote>
<br>
It's a botch that developers avoid, else they jank the user interface. We've been over this. Are you seriously defending it?<br>
<br>
SyncXHR is anti-precedent.<br>
<br>
/be<br>
<br>
<br><br>---------- Weitergeleitete Nachricht ----------<br>From: Brendan Eich <<a href="mailto:brendan@mozilla.org" target="_blank">brendan@mozilla.org</a>><br>To: Jason Orendorff <<a href="mailto:jason.orendorff@gmail.com" target="_blank">jason.orendorff@gmail.com</a>><br>


Cc: ES-Discuss <<a href="mailto:es-discuss@mozilla.org" target="_blank">es-discuss@mozilla.org</a>><br>Date: Thu, 05 Jul 2012 18:18:46 -0700<br>Subject: Re: for-of statement of sparse array<br>Brendan Eich wrote:<br>


<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
This upholes the Array forEach (and all other extras) hole-skipping. The deck is stacked against for(;;) iteration in my view.<br>
</blockquote>
<br>
LOL, "This upholds", of course.<br>
<br>
/be<br>
<br>
<br><br>---------- Weitergeleitete Nachricht ----------<br>From: Rick Waldron <<a href="mailto:waldron.rick@gmail.com" target="_blank">waldron.rick@gmail.com</a>><br>To: Brendan Eich <<a href="mailto:brendan@mozilla.org" target="_blank">brendan@mozilla.org</a>><br>


Cc: ES-Discuss <<a href="mailto:es-discuss@mozilla.org" target="_blank">es-discuss@mozilla.org</a>><br>Date: Thu, 5 Jul 2012 21:30:44 -0400<br>Subject: Re: for-of statement of sparse array<br>
    <div><br></div>
     
    <p style="color:#a0a0a8">On Thursday, July 5, 2012 at 9:18 PM, Brendan Eich wrote:</p>
    <blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px">
        <div><div><div>Brendan Eich wrote:</div><blockquote type="cite"><div><div>This upholes the Array forEach (and all other extras) hole-skipping. </div><div>The deck is stacked against for(;;) iteration in my view.</div>


</div></blockquote><div><br></div><div>LOL, "This upholds", of course.</div><div><br></div></div></div></blockquote><div>I had hoped this was a clever pun :)</div><div><br></div><div><br></div><div>Currently, devs expect for-loop and while (assuming common patterns in play here) to be "the expected" way that sparse array holes are exposed -- so from the "give me what I most likely expect" perspective, I agree with the consistency wins argument: for-of should act like for-in </div>


<div><br></div><div>Rick</div><blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px"><div><div><div></div><div>/be</div><div>_______________________________________________</div>


<div>es-discuss mailing list</div><div><a href="mailto:es-discuss@mozilla.org" target="_blank">es-discuss@mozilla.org</a></div><div><a href="https://mail.mozilla.org/listinfo/es-discuss" target="_blank">https://mail.mozilla.org/listinfo/es-discuss</a></div>


</div></div>
         
         
         
         
    </blockquote>
     
    <div>
        <br>
    </div>
<br><br>---------- Weitergeleitete Nachricht ----------<br>From: Brendan Eich <<a href="mailto:brendan@mozilla.org" target="_blank">brendan@mozilla.org</a>><br>To: Boris Zbarsky <<a href="mailto:bzbarsky@mozilla.com" target="_blank">bzbarsky@mozilla.com</a>><br>


Cc: Patrik Stutz <<a href="mailto:patrik.stutz@gmail.com" target="_blank">patrik.stutz@gmail.com</a>>, <a href="mailto:es-discuss@mozilla.org" target="_blank">es-discuss@mozilla.org</a><br>Date: Thu, 05 Jul 2012 19:37:11 -0700<br>

Subject: Re: Fwd: "delay" keyword<br>
Boris Zbarsky wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Note that I say "most".  There are some fundamental problems here.  Say the user decides to close the tab or window when they get the slow script prompt (something that I think is desirable to allow the user to do, personally).  Should this close the tab/window without firing unload events (a spec violation) or should it fire them while other script from the page is on the stack and at some random point in its execution (hey, another spec violation)?<br>



</blockquote>
<br>
Does the spec really mandate onunload etc. definitely being called in all cases? That is impossible in a great number of cases (machine hard reset, e.g.) and anyway it enables DoS attacks.<br>
<br>
Forgenerators in JS1.7 and up, which have a close method that is called when the generator is iterated by a for-in loop (for-of in ES6, I presume), we long ago decided that close may never happen, precisely to prevent DoS problems (accidental, on purpose, doesn't matter).<br>



<br>
/be<br>
<br>
<br>
<br>_______________________________________________<br>
es-discuss mailing list<br>
<a href="mailto:es-discuss@mozilla.org" target="_blank">es-discuss@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/es-discuss" target="_blank">https://mail.mozilla.org/listinfo/es-discuss</a><br>
<br></blockquote></div><br></div>
</div></div>
<br>_______________________________________________<br>
es-discuss mailing list<br>
<a href="mailto:es-discuss@mozilla.org">es-discuss@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/es-discuss" target="_blank">https://mail.mozilla.org/listinfo/es-discuss</a><br>
<br></blockquote></div><br>