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.
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.
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:
var content
fs.readFile('blah.txt', function (e, data) {
if (e) throw e
content = data
}, 'utf8')
wait
// Do something with content
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.
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.
Cheers,
Jussi
On Fri, Jul 6, 2012 at 12:03 PM, Patrik Stutz <patrik.st...@gmail.com>wrote:
> 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-requ...@mozilla.org>
>
>> Send es-discuss mailing list submissions to
>> es-discuss@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-requ...@mozilla.org
>>
>> You can reach the person managing the list at
>> es-discuss-ow...@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.orendo...@gmail.com>
>> To: Allen Wirfs-Brock <al...@wirfs-brock.com>
>> Cc: Brendan Eich <bren...@mozilla.org>, ES-Discuss <
>> es-discuss@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 <al...@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 <vitteayme...@gmail.com>
>> To: Sam Tobin-Hochstadt <sa...@ccs.neu.edu>
>> Cc: Brendan Eich <bren...@mozilla.org>, "es-discuss@mozilla.org" <
>> es-discuss@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 : avi...@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 <bren...@mozilla.org>
>> To: Jason Orendorff <jason.orendo...@gmail.com>
>> Cc: ES-Discuss <es-discuss@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<bren...@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 <bren...@mozilla.org>
>> To: Jason Orendorff <jason.orendo...@gmail.com>
>> Cc: ES-Discuss <es-discuss@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@wirfs-brock.**
>>> com <al...@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 <bren...@mozilla.org>
>> To: Aymeric Vitte <vitteayme...@gmail.com>
>> Cc: "es-discuss@mozilla.org" <es-discuss@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 <bren...@mozilla.org>
>> To: Jason Orendorff <jason.orendo...@gmail.com>
>> Cc: ES-Discuss <es-discuss@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.r...@gmail.com>
>> To: Brendan Eich <bren...@mozilla.org>
>> Cc: ES-Discuss <es-discuss@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@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>>
>>
>> ---------- Weitergeleitete Nachricht ----------
>> From: Brendan Eich <bren...@mozilla.org>
>> To: Boris Zbarsky <bzbar...@mozilla.com>
>> Cc: Patrik Stutz <patrik.st...@gmail.com>, es-discuss@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@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
