es-discuss Digest, Vol 65, Issue 29

Patrik Stutz patrik.stutz at gmail.com
Fri Jul 6 02:03:12 PDT 2012


Just to be sure I understood that thing right.

When this is the "stack" of the example by Jussi Kalliokoski (other colors
mean other queue entry)

   - console.log("1");
   - console.log("2");
   - wait;
   - console.log("5");
   - console.log("3");
   - console.log("4");

The wait keyword made it execute this way:

   - console.log("1");
   - console.log("2");
      - console.log("3");
      - console.log("4");
   - console.log("5");

Instead of this way:

   - console.log("1");
   - console.log("2");
   - console.log("3");
   - console.log("4");
   - console.log("5");

?

Ok, that's not how I suggested it to work. But to be honest, I think this
approach is event better!
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.

You say that's a bug and this will indeed be right, but what about adding
such a functionality to the spec?
I think the argument about "to hard to implement" would be gone this way,
right?





2012/7/6 <es-discuss-request at mozilla.org>

> Send es-discuss mailing list submissions to
>         es-discuss at mozilla.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://mail.mozilla.org/listinfo/es-discuss
> or, via email, send a message with subject or body 'help' to
>         es-discuss-request at mozilla.org
>
> You can reach the person managing the list at
>         es-discuss-owner at mozilla.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of es-discuss digest..."
>
> Today's Topics:
>
>    1. Re: for-of statement of sparse array (Jason Orendorff)
>    2. Re: Static Module Resolution (Aymeric Vitte)
>    3. Re: for-of statement of sparse array (Brendan Eich)
>    4. Re: for-of statement of sparse array (Brendan Eich)
>    5. Re: Static Module Resolution (Brendan Eich)
>    6. Re: for-of statement of sparse array (Brendan Eich)
>    7. Re: for-of statement of sparse array (Rick Waldron)
>    8. Re: Fwd: "delay" keyword (Brendan Eich)
>
>
> ---------- Weitergeleitete Nachricht ----------
> From: Jason Orendorff <jason.orendorff at gmail.com>
> To: Allen Wirfs-Brock <allen at wirfs-brock.com>
> Cc: Brendan Eich <brendan at mozilla.org>, ES-Discuss <es-discuss at mozilla.org
> >
> Date: Thu, 5 Jul 2012 18:10:29 -0500
> Subject: Re: for-of statement of sparse array
> On Thu, Jul 5, 2012 at 2:09 PM, Allen Wirfs-Brock <allen at wirfs-brock.com>
> wrote:
> >> Map may win at some point, who knows? It's not winning if one wants an
> array, numeric indexing, .length, the usual prototype methods.
> >
> > We could consider also have "dense" interators available:
> >
> >      for (let v of array.denseValues) console.log(v);
>
> This makes sense to me, but most arrays are meant to be dense in
> practice. So perhaps it makes more sense to add methods specifically
> for sparse arrays, making developers type more characters in the rare
> case rather than the common case:
>
>     for (let v of array.sparseValues()) ...;
>     for (let [i, v] of array.sparseItems()) ...;
>
> -j
>
>
>
> ---------- Weitergeleitete Nachricht ----------
> From: Aymeric Vitte <vitteaymeric at gmail.com>
> To: Sam Tobin-Hochstadt <samth at ccs.neu.edu>
> Cc: Brendan Eich <brendan at mozilla.org>, "es-discuss at mozilla.org" <
> es-discuss at mozilla.org>
> Date: Fri, 06 Jul 2012 01:15:09 +0200
> Subject: Re: Static Module Resolution
>
>  I don't understand your comment about `window` and `document`.  They
>> are already globals in browser JS environments.
>>
> 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)
>
>>
>> As for async, there are a variety of ways to make it easier
>>
> 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.**createElement('script') callbacks, modules are
> reproducing the same
>
> I don't know if you develop everyday async code handling multiple asyncs
> stuff but it becomes all the time very quickly a nightmare
>
>> , but we
>> are *not* going to add synchronous IO as part of the module system.
>> The run-to-completion semantics of JS are non-negotiable.
>>
> Then the sync xhr is absurd ?
>
> 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
>
> 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)
>
> --
> jCore
> Email :  avitte at jcore.fr
> Web :    www.jcore.fr
> Webble : www.webble.it
> Extract Widget Mobile : www.extractwidget.com
> BlimpMe! : www.blimpme.com
>
>
>
>
>
>
> ---------- Weitergeleitete Nachricht ----------
> From: Brendan Eich <brendan at mozilla.org>
> To: Jason Orendorff <jason.orendorff at gmail.com>
> Cc: ES-Discuss <es-discuss at mozilla.org>
> Date: Thu, 05 Jul 2012 18:12:22 -0700
> Subject: Re: for-of statement of sparse array
> Jason Orendorff wrote:
>
>> On Thu, Jul 5, 2012 at 12:54 PM, Brendan Eich<brendan at mozilla.org>
>>  wrote:
>>
>>> Allen privately observed that Array forEach skips holes, matching for-in.
>>> That counts for a lot with me -- we have only a blind
>>> for(i=0;i<a.length;i++)... loop not skipping holes, but of course it
>>> wouldn't. That is weak precedent on which to build for-of.
>>>
>>
>> In what sense is that precedent weak? It seems a stronger precedent
>> than forEach on every axis; arguably it's one of the most-trodden
>> cowpaths in programming, in any language.
>>
>
> 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.
>
>  for-in is a kind of anti-precedent, for array iteration.
>>
>
> 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.
>
>  Map may win at some point, who knows? It's not winning if one wants
>>> an array, numeric indexing, .length, the usual prototype methods.
>>>
>>
>> I agree Map is somewhat beside the point. TC39 should spec what's best
>> for developers net of everything. Even if that's matching for-in. But
>> the purpose of for-of is to address the shortcomings of for-in;
>> following it just for the sake of consistency would be self-defeating.
>>
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> Reasoning about latent bugs due to skipping holes is perilous and wants
> empirical studies, some evidence, a few burning anecdotes. Got any?
>
> /be
>
>
>
> ---------- Weitergeleitete Nachricht ----------
> From: Brendan Eich <brendan at mozilla.org>
> To: Jason Orendorff <jason.orendorff at gmail.com>
> Cc: ES-Discuss <es-discuss at mozilla.org>
> Date: Thu, 05 Jul 2012 18:15:50 -0700
> Subject: Re: for-of statement of sparse array
> Jason Orendorff wrote:
>
>> On Thu, Jul 5, 2012 at 2:09 PM, Allen Wirfs-Brock<allen at wirfs-brock.**com<allen at wirfs-brock.com>>
>>  wrote:
>>
>>> Map may win at some point, who knows? It's not winning if one wants an
>>>> array, numeric indexing, .length, the usual prototype methods.
>>>>
>>> We could consider also have "dense" interators available:
>>>
>>>       for (let v of array.denseValues) console.log(v);
>>>
>>
>> This makes sense to me, but most arrays are meant to be dense in
>> practice. So perhaps it makes more sense to add methods specifically
>> for sparse arrays, making developers type more characters in the rare
>> case rather than the common case:
>>
>>      for (let v of array.sparseValues()) ...;
>>      for (let [i, v] of array.sparseItems()) ...;
>>
>
> 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.
>
> 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.
>
> 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.
>
> /be
>
>
>
> ---------- Weitergeleitete Nachricht ----------
> From: Brendan Eich <brendan at mozilla.org>
> To: Aymeric Vitte <vitteaymeric at gmail.com>
> Cc: "es-discuss at mozilla.org" <es-discuss at mozilla.org>
> Date: Thu, 05 Jul 2012 18:17:06 -0700
> Subject: Re: Static Module Resolution
> Aymeric Vitte wrote:
>
>> Then the sync xhr is absurd ?
>>
>
> It's a botch that developers avoid, else they jank the user interface.
> We've been over this. Are you seriously defending it?
>
> SyncXHR is anti-precedent.
>
> /be
>
>
>
> ---------- Weitergeleitete Nachricht ----------
> From: Brendan Eich <brendan at mozilla.org>
> To: Jason Orendorff <jason.orendorff at gmail.com>
> Cc: ES-Discuss <es-discuss at mozilla.org>
> Date: Thu, 05 Jul 2012 18:18:46 -0700
> Subject: Re: for-of statement of sparse array
> Brendan Eich wrote:
>
>> This upholes the Array forEach (and all other extras) hole-skipping. The
>> deck is stacked against for(;;) iteration in my view.
>>
>
> LOL, "This upholds", of course.
>
> /be
>
>
>
> ---------- Weitergeleitete Nachricht ----------
> From: Rick Waldron <waldron.rick at gmail.com>
> To: Brendan Eich <brendan at mozilla.org>
> Cc: ES-Discuss <es-discuss at mozilla.org>
> Date: Thu, 5 Jul 2012 21:30:44 -0400
> Subject: Re: for-of statement of sparse array
>
> On Thursday, July 5, 2012 at 9:18 PM, Brendan Eich wrote:
>
> Brendan Eich wrote:
>
> This upholes the Array forEach (and all other extras) hole-skipping.
> The deck is stacked against for(;;) iteration in my view.
>
>
> LOL, "This upholds", of course.
>
> I had hoped this was a clever pun :)
>
>
> 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
>
> Rick
>
> /be
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
>
>
> ---------- Weitergeleitete Nachricht ----------
> From: Brendan Eich <brendan at mozilla.org>
> To: Boris Zbarsky <bzbarsky at mozilla.com>
> Cc: Patrik Stutz <patrik.stutz at gmail.com>, es-discuss at mozilla.org
> Date: Thu, 05 Jul 2012 19:37:11 -0700
> Subject: Re: Fwd: "delay" keyword
> Boris Zbarsky wrote:
>
>> 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)?
>>
>
> 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.
>
> 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).
>
> /be
>
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120706/475477aa/attachment-0001.html>


More information about the es-discuss mailing list