Iteration protocol: a sentinel value?
In the TC39 meeting notes, Mark suggested something similar (but more
sophisticated) which was rejected and I am wondering why.
Herman’s protocol is (roughly):
- Values v: { value: v }
- After last value: { done: true }
With a sentinel value, this would look like:
- Values v: v
- After last value: SENTINEL_VALUE (defined once, somewhere)
The latter seems simpler to me – what’s wrong with it?
Thanks!
Axel
--
Dr. Axel Rauschmayer
a...@rauschma.de
home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Iteration protocol: a sentinel value?
The sentinel cannot carry a return value, from the notes:
DH: Mark's proposal is broken, because it doesn't work with return
values of generators.
MM: Agreed.
In the TC39 meeting notes, Mark suggested something similar (but more
sophisticated) which was rejected and I am wondering why.
Herman's protocol is (roughly):
- Values v: { value: v }
- After last value: { done: true }
With a sentinel value, this would look like:
- Values v: v
- After last value: SENTINEL_VALUE (defined once, somewhere)
The latter seems simpler to me -- what's wrong with it?
Thanks!
Axel
--
Dr. Axel Rauschmayer
axel at rauschma.de https://mail.mozilla.org/listinfo/es-discuss
home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Iteration protocol: a sentinel value?
Thanks! Can you elaborate?
On May 14, 2013, at 9:20 , André Bargull andre.barg...@udo.edu wrote:
The sentinel cannot carry a return value, from the notes:
DH: Mark's proposal is broken, because it doesn't work with return values of
generators.
MM: Agreed.
In the TC39 meeting notes, Mark suggested something similar (but more
sophisticated) which was rejected and I am wondering why.
Herman’s protocol is (roughly):
- Values v: { value: v }
- After last value: { done: true }
With a sentinel value, this would look like:
- Values v: v
- After last value: SENTINEL_VALUE (defined once, somewhere)
The latter seems simpler to me – what’s wrong with it?
--
Dr. Axel Rauschmayer
a...@rauschma.de
home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Future feedback
On 13/05/2013, at 05:37, Jonas Sicking wrote:
On Sun, May 12, 2013 at 7:31 PM, Boris Zbarsky bzbar...@mit.edu wrote:
Moreover the page can be reflowed between tasks.
_ANY_ async solution will have this property. What does it even mean to be
async if you don't allow reflows in the meantime?
Work that is performed at end-of-microtask is sort of between fully
asynchronous and normal synchronous. Since it runs as part of the same
task it means that reflows can't happen before the end-of-microtask
work happens.
This means that you get some advantages of asynchronous code, such as
not having to worry about being in an inconsistent state due to code
higher up on the call stack being half-run. And likewise you don't
have to worry about not messing up code higher up on the callstack
which didn't expect to have things change under it.
But it also means that you are missing out of some of the advantages
of asynchronous code, such as you still have to worry about hogging
the event loop for too long and thus not processing pending UI events
from the user.
The event loops used to look ~ like this (node's nextTick used to be ===
setImmediate):
while ( RUN ) {
despatchSetImmediate();
despatchIOandGUIandTimerEvents();
if (!setImmediateQueue.length !pendingEventsSignal) sleep();
}
IIUC now node's (new) event loop looks ~ like this instead (now that nextTick
!== setImmediate):
while ( RUN ) {
despatchSetImmediate();
despatchNextTickQueue();
despatchIOandGUIandTimerEvents();
if (!setImmediateQueue.length !nextTickQueue.length
!pendingEventsSignal) sleep();
}
despatchNextTickQueue() unlike despatchSetImmediate() walks its queue entirely
(simplified pseudo code):
function despatchSetImmediate () {
var queue= setImmediateQueue;
setImmediateQueue= [];
for (var i=0 ; i queue.length ; i++) queue[i]();
}
function despatchNextTickQueue () {
for (var i=0 ; i nextTickQueue.length ; i++) nextTickQueue[i]();
nextTickQueue.length= 0;
}
If a nextTick()ed function adds further nextTick()ed functions, those newly
added functions will run in the *current* tick as well, unlike setImmediate()ed
functions, which seems to be the whole point of this modified, new event loop.
Bus this also means that if nextTicked functions call nextTick() recursively
the event loop blocks!
To solve that they've added a counter into despatchNextTickQueue() so that it
won't ever walk in a single tick more than n elements of the nextTickQueue.
Now that means that nextTick()ed functions may sometimes behave as if
setImmediate()d: you never know for sure.
To have a new event loop model that may block is a bad thing IMO, and the
let's add a counter solution isn't a good solution.
Before the mod always knew what was going to happen, now you don't.
--
( Jorge )();
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Iteration protocol: a sentinel value?
`return expression` is allowed within a generator [1] and to be able
to retrieve the expression's value, a (possibly frozen) sentinel value
doesn't quite work.
A simple example:
function* gen() {
return 123;
}
var {value, done} = gen().next();
assertEq(done, true);
assertEq(value, 123);
[1] http://wiki.ecmascript.org/doku.php?id=harmony:generators#returning
On 5/14/2013 1:32 PM, Axel Rauschmayer wrote:
Thanks! Can you elaborate?
On May 14, 2013, at 9:20 , André Bargull andre.barg...@udo.edu
mailto:andre.barg...@udo.edu wrote:
The sentinel cannot carry a return value, from the notes:
DH: Mark's proposal is broken, because it doesn't work with return
values of generators.
MM: Agreed.
In the TC39 meeting notes, Mark suggested something similar (but more
sophisticated) which was rejected and I am wondering why.
Herman’s protocol is (roughly):
- Values v: { value: v }
- After last value: { done: true }
With a sentinel value, this would look like:
- Values v: v
- After last value: SENTINEL_VALUE (defined once, somewhere)
The latter seems simpler to me – what’s wrong with it?
--
Dr. Axel Rauschmayer
a...@rauschma.de mailto:a...@rauschma.de
home: rauschma.de http://rauschma.de
twitter: twitter.com/rauschma http://twitter.com/rauschma
blog: 2ality.com http://2ality.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Iteration protocol: a sentinel value?
I’m guessing that the semantics are not negotiable, but if they were, I would
let an empty `return` terminate the generator, while
return expr;
would be synonymous to
yield expr;
return;
That would more clearly separate concerns – I’m not too fond of the stopping
mechanism (be it {done} or StopIteration) having to play double duty.
On May 14, 2013, at 13:46 , André Bargull andre.barg...@udo.edu wrote:
`return expression` is allowed within a generator [1] and to be able to
retrieve the expression's value, a (possibly frozen) sentinel value doesn't
quite work.
A simple example:
function* gen() {
return 123;
}
var {value, done} = gen().next();
assertEq(done, true);
assertEq(value, 123);
[1] http://wiki.ecmascript.org/doku.php?id=harmony:generators#returning
--
Dr. Axel Rauschmayer
a...@rauschma.de
home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Module naming and declarations
That's just an outlandish statement, Kevin. I'm talking making a common
refactoring semantically equivalent -- a refactoring that's well-motivated
by a common use case: *programmers* solving their network efficiency issues
by controlling which modules are loaded when. It's not some magical
construct that automatically solves network issues.
Sorry.
As far as I can tell, the only use case for module registrations that isn't
adequately covered by lexical module declarations is multiplexing. Thanks
for pointing that out. Of course, the general solution for multiplexing of
resources on the web is at the network protocol layer. That is the
end-game and from my point of view other techniques (i.e. image spriting)
are stop-gaps.
It is possible to fill that gap without registration syntax using a small
module loader plugin and a simple multiplexing tool, but I understand the
desire to make such tooling unnecessary.
{ Kevin }
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: yield* desugaring
On May 13, 2013, at 9:44 PM, Brendan Eich wrote:
David Herman wrote:
On May 13, 2013, at 6:11 PM, Brendan Eichbren...@mozilla.com wrote:
Merge next and send by letting next take an optional parameter? Ok by me.
+1
I pointed out to Dave that Python has arity checking and did next before
adding send in 2.5 for coroutines, whereas JS has optional params without
arity checking, so folding send into next works.
Make yield* work on any {next, throw}, not necessary but ok by me too.
Yes with one delta: if there's no .throw it still works, it just defaults to
(x) = { throw x }. This way you can write ordinary iterators without
having to worry about providing the default throw, and they still function
properly as generators.
+1 or more -- we should not invent new nominal types with stub throw method
implementations, people will not use them and they are unnecessary
boilerplate.
/be
All sounds fine with me and I've updated the draft accordingly.
What about providing a convenience resume method on generators to help
clarify co-routine style usage? Dave suggested that resume was pedagogically
useful.
I would define it equivalently two:
resume(...args) {return this.next(...args};
(resume rather than next delegates to avoid the delegation for normal for-of
iterations)
Allen
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: yield* desugaring
On 14 May 2013 17:07, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
What about providing a convenience resume method on generators to help
clarify co-routine style usage? Dave suggested that resume was
pedagogically useful.
I would define it equivalently two:
resume(...args) {return this.next(...args};
(resume rather than next delegates to avoid the delegation for normal for-of
iterations)
Not sure about having two names for the same method, but if so, why
not simply make Generator.prototype.resume ===
Generator.prototype.next?
/Andreas
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: yield* desugaring
On May 14, 2013, at 8:12 AM, Andreas Rossberg wrote:
On 14 May 2013 17:07, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
What about providing a convenience resume method on generators to help
clarify co-routine style usage? Dave suggested that resume was
pedagogically useful.
I would define it equivalently two:
resume(...args) {return this.next(...args};
(resume rather than next delegates to avoid the delegation for normal for-of
iterations)
Not sure about having two names for the same method, but if so, why
not simply make Generator.prototype.resume ===
Generator.prototype.next?
It could me done that way. I'm not so sure it is such a good practice.
GeneratorFunctions are constructors and hence each one provide a unique
prototype object for all its instances. So, conceivably a developer can
over-ride either or both of next and resume for a particular family of
generators. Specify one as explicitly delegating to the other in the
superclass makes it clearer which method you need to over-ride if you want to
modify both next and resume behavior. Otherwise, you would always have to
remember to over-ride both.
Allen
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: yield* desugaring
Two names seems like a bad compromise. We should either do `next(...args)`
or `resume(...args)`. Not both.
On Tue, May 14, 2013 at 11:12 AM, Andreas Rossberg rossb...@google.comwrote:
On 14 May 2013 17:07, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
What about providing a convenience resume method on generators to help
clarify co-routine style usage? Dave suggested that resume was
pedagogically useful.
I would define it equivalently two:
resume(...args) {return this.next(...args};
(resume rather than next delegates to avoid the delegation for normal
for-of iterations)
Not sure about having two names for the same method, but if so, why
not simply make Generator.prototype.resume ===
Generator.prototype.next?
/Andreas
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
erik
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: yield* desugaring
Erik Arvidsson wrote:
Two names seems like a bad compromise. We should either do
`next(...args)` or `resume(...args)`. Not both.
Right, and 'resume' makes no sense for iterators.
C'mon you two whose names start with A: this bikeshedding is wasteful
and disharmonious. We have much bigger fish to fry. Now is not the time
to be messing around. That is all :-|.
/be
On Tue, May 14, 2013 at 11:12 AM, Andreas Rossberg
rossb...@google.com mailto:rossb...@google.com wrote:
On 14 May 2013 17:07, Allen Wirfs-Brock al...@wirfs-brock.com
mailto:al...@wirfs-brock.com wrote:
What about providing a convenience resume method on generators
to help clarify co-routine style usage? Dave suggested that
resume was pedagogically useful.
I would define it equivalently two:
resume(...args) {return this.next(...args};
(resume rather than next delegates to avoid the delegation for
normal for-of iterations)
Not sure about having two names for the same method, but if so, why
not simply make Generator.prototype.resume ===
Generator.prototype.next?
/Andreas
___
es-discuss mailing list
es-discuss@mozilla.org mailto:es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
erik
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Iteration protocol: a sentinel value?
Please re-read
http://wiki.ecmascript.org/doku.php?id=harmony:generators#returning
and
http://www.python.org/dev/peps/pep-0380/
/be
Axel Rauschmayer wrote:
I’m guessing that the semantics are not negotiable, but if they were,
I would let an empty `return` terminate the generator, while
return expr;
would be synonymous to
yield expr;
return;
That would more clearly separate concerns – I’m not too fond of the
stopping mechanism (be it {done} or StopIteration) having to play
double duty.
On May 14, 2013, at 13:46 , André Bargull andre.barg...@udo.edu
mailto:andre.barg...@udo.edu wrote:
`return expression` is allowed within a generator [1] and to be
able to retrieve the expression's value, a (possibly frozen)
sentinel value doesn't quite work.
A simple example:
function* gen() {
return 123;
}
var {value, done} = gen().next();
assertEq(done, true);
assertEq(value, 123);
[1] http://wiki.ecmascript.org/doku.php?id=harmony:generators#returning
--
Dr. Axel Rauschmayer
a...@rauschma.de mailto:a...@rauschma.de
home: rauschma.de http://rauschma.de
twitter: twitter.com/rauschma http://twitter.com/rauschma
blog: 2ality.com http://2ality.com
___
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: Module naming and declarations
On Tue, May 7, 2013 at 2:12 PM, Anne van Kesteren ann...@annevk.nl wrote: On Tue, May 7, 2013 at 2:00 PM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote: 0. If we have an absolute URL, skip steps 1-3. How do you define this? We currently do not have this concept really. I found a standard that defines this! An absolute URL is a URL http://url.spec.whatwg.org/#concept-url with a scheme http://url.spec.whatwg.org/#concept-url-scheme. [1] [1] URL living standard http://url.spec.whatwg.org/. Anne van Kesteren, editor. -j ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Module naming and declarations
On Tue, May 14, 2013 at 2:03 PM, Jason Orendorff jason.orendo...@gmail.com wrote: I found a standard that defines this! An absolute URL is a URL with a scheme. That doesn't mean we use this concept in the platform anywhere. (And also, what I pointed out earlier about scheme:bits, base - parser - serializer - something else, base is also still true for relative schemes.) -- http://annevankesteren.nl/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Module naming and declarations
On Tue, May 14, 2013 at 2:16 PM, Anne van Kesteren ann...@annevk.nl wrote: On Tue, May 14, 2013 at 2:03 PM, Jason Orendorff jason.orendo...@gmail.com wrote: I found a standard that defines this! An absolute URL is a URL with a scheme. That doesn't mean we use this concept in the platform anywhere. (And also, what I pointed out earlier about scheme:bits, base - parser - serializer - something else, base is also still true for relative schemes.) Right, I understand and agree on both points, I just had to smile when I ran across that today and realized you wrote it. Missing smiley in the post, sorry. Here it is... :-D Better late than never, -j :-D ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Module naming and declarations
On Tue, May 14, 2013 at 10:16 PM, Anne van Kesteren ann...@annevk.nl wrote: On Tue, May 14, 2013 at 2:03 PM, Jason Orendorff jason.orendo...@gmail.com wrote: I found a standard that defines this! An absolute URL is a URL with a scheme. That doesn't mean we use this concept in the platform anywhere. Dear Anne, Though this does not directly bear on the module discussion at hand, I have tired of your continued spreading of misinformation regarding URIs. Surely you must be mistaken in your repeated assertions against the fixed notion of absolute URL? Perhaps you mean no decision procedure exists for relative-scheme URL absoluteness? I believe such a procedure does exist and you have already attempted to specify it. In your own document, you define a base URL as an absolute URL http://url.spec.whatwg.org/#concept-base-url. By your own example https://mail.mozilla.org/pipermail/es-discuss/2013-May/030557.html, there are URLs with schemes that are not absolute. This contradicts your WHATWG document which purports to reflect browser implementations. Though it https://mail.mozilla.org/pipermail/es-discuss/2013-May/030559.html is not a mathematically constructive definition, a very concrete definition of absolute URI as universal fixpoint exists. I am certain that a constructive definition also exists. In fact, you have already specified one. The primary use of absolute URLs is *unambiguity* (aside: many specs refer to URIs as if they are all absolute and use the term relative URI or relative reference for non-absolute URIs). They are widely used and their properties relied upon in many documents, programs, and interfaces. Your own parsing/normalizing/resolving procedure in your URL document *only* defines a representation for absolute URLs: Parsing (provided it does not return failure) and serializing a URL will turn it into an absolute URL. There are many standards that do not define relative resolution of URL references and instead require an absolute URL. Many of these standards seem to get by with a reference to STD66's absolute URI ABNF production. To wit: WHATWGML defines http://www.whatwg.org/specs/web-apps/current-work/multipage/the-input-element.html#attr-input-type-keywords the url input element type attribute as producing An absolute URL http://www.whatwg.org/specs/web-apps/current-work/multipage/states-of-the-type-attribute.html#url-state-%28type=url%29. Applications will rely on this type when processing. WHATWGML mandates http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#other-link-types that other link types having a COLON : must be absolute URLs. WHATWGML's @itemprop tokens http://www.whatwg.org/specs/web-apps/current-work/#names:-the-itemprop-attribute for typed items may be absolute URLs but not relative URL references. RFC 4395 Guidelines and Registration Procedures for New URI Schemes requires http://tools.ietf.org/html/rfc4395#section-2.2 new schemes define absolute syntaxes and avoid notation used by relative schemes for relative references. XML namespaces, XPath, etc also use absolute URLs http://lists.w3.org/Archives/Public/xml-uri/2000Sep/0083.html. RFC 3404 DDDS only http://tools.ietf.org/html/rfc3404#section-4.1 resolves absolute URLs. RFC 2326 RTSP requests use http://tools.ietf.org/html/rfc2326#page-21 absolute URLs only. RFC 5842 WebDAV Binding Extensions use absolute URIs in URI Mappings http://tools.ietf.org/html/rfc5842#section-1.1. Maximally interoperable server implementations of the HTTP 1.1 (RFC 2616) Location header http://tools.ietf.org/html/rfc2616#section-14.30 emit only absolute URLs. RFC 4468 Message Submission BURL Extension defines a new SMTP command to retrieve data from an absolute IMAP URL http://tools.ietf.org/html/rfc4468#section-3.5. RFC 6749 OAuth 2.0 Authorization Framework, though troubled, requires absolute URLs for endpoints http://tools.ietf.org/html/rfc6749#section-3.1.2 as well as extension grant types http://tools.ietf.org/html/rfc6749#section-4.5 and access token types http://tools.ietf.org/html/rfc6749#section-8.1. RFC 6066 (proposed) Transport Layer Security (TLS) Extensions: Extension Definitions defines http://tools.ietf.org/html/rfc6066#section-5 client certificate URLs that must be absolute. RFC 6134 (proposed) Sieve Extension: Externally Stored Lists for email filtering defines the name of externally stored lists http://tools.ietf.org/html/rfc6134#section-2.5 as always an absolute URI. This is only a partial list from a short bout of research. I'm sure if you exert yourself, you will discover that you were mistaken. Sincerely, David ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Future feedback
AFAICT, the microtask queue is just another output queue, and the strict priority of the microtask queue over other queues is just a policy choice of which outgoing queue to service next. The input queue model could not guarantee strict priority without creating a two level queue. The outgoing queue model keeps this separate with no loss of generality. Cool. On Tue, May 14, 2013 at 5:54 PM, Mark S. Miller erig...@google.com wrote: -- Forwarded message -- From: Mark S. Miller erig...@google.com Date: Tue, May 14, 2013 at 4:54 PM Subject: Re: Future feedback To: Boris Zbarsky bzbar...@mit.edu Cc: David Bruant bruan...@gmail.com, Sean Hogan shogu...@westnet.com.au, Jonas Sicking jo...@sicking.cc, public-script-co...@w3.org public-script-co...@w3.org I see. I was thinking primarily about incoming queues whereas this formulates the issue primarily in terms of outgoing queues. Rather than have a non-deterministic interleaving of events into the incoming queue, which then services them later, this just moves the non-deterministic choice as late as possible, at the point when the next turn is ready to start. This effectively removes the notion of an incoming queue from the model. Curiously, this is how Ken https://www.usenix.org/conference/usenixfederatedconferencesweek/composable-reliability-asynchronous-systems-treating and NodeKen http://research.google.com/pubs/pub40673.html treat the persistent storage of distributed messages. The incoming queues are ephemeral, outgoing messages are not dropped until receipt has been acknowledged, and messages are not acknowledged until processed by a turn that has been checkpointed. On restart a different interleaving may be chosen, which the incoming queue model would have a harder time accounting for. I like it. AFAICT, this is a better way to specify communicating event loops in all ways. Thanks! On Tue, May 14, 2013 at 7:03 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 5/14/13 9:04 AM, David Bruant wrote: http://lists.w3.org/Archives/**Public/public-script-coord/** 2013AprJun/0167.htmlhttp://lists.w3.org/Archives/Public/public-script-coord/2013AprJun/0167.html I should note that the description of the browser event loop in that message is wrong. It does not have only two FIFO queues in the specs, or in implementations. In particular, see task sources. I would be strongly opposed to specifying something that requires only two FIFO queues. -Boris -- Cheers, --MarkM -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Text by me above is hereby placed in the public domain Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
A new ES6 spec. draft has been posted
At the usual place: http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts Changes include: Made Symbols a primitive type Added semantics for generator function and generator method definitions Added semantics for array comprehensions and generator comprehensions Added semantics for yield and yield* Replaced StopIteration exception with nextResult objects Updated for-in/of semantics to use new generator protocol Made Arrow function and concise method formal parameters “strict” Added Object.setPrototypeOf function Made Function constructor subclassable Added Array.prototype.find and findIndex Added Math.imul Added ArrayBuffer.isView to check for ArrayBuffer view objects Added Clause 15.19 defining the content of the build-in iteration module. Coontains built-ins needed to support generators Disallow Unicode escapes as RegularExpressionFlags Moved Object.prototype.__proto__ back to Annex B. It’s a simple access or that is not Realm specific. Added in Annex B __proto__ property keys in object literals Added placeholder in Annex B for defining syntax of html-like comments In Annex B, first cut at block-level function declaration legacy semantics Added RegExp.prototype.compile to Annexs B Fixed handling of negative integer indices for typed arrays. Elimiante ToPositiveInteger abstract operation Typed Arrays are allowed to stre values using native endianess. Fixed various bugs in class declaration semantics Dates never expose -0 as a time value Resolved Bugs: 1469, 1461-1460, 1458, 1452-1451, 1449, 1446, 1442-1435, 1433, 1432-1414, 1411-1407, 1404, 1403-1401, 1399-1397, 1395-1392, 1389-1376, 1374-1366, 1363-1361, 1359, 1357-1355, 1352-1348, 1346, 1344-1342, 1340-1338, 1336-1318, 1316, 1314-1301, 1299-1296, 1294-1291, 1289-1288, 1286-1285, 1284, 1282, 1280-1277, 1272, 1253, 1117 Allen___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: A new ES6 spec. draft has been posted
Great! Now [[Call]] doesn't return a Reference type, so I think issue[1] can be closed, right? [1]: https://bugs.ecmascript.org/show_bug.cgi?id=387 On Wed, May 15, 2013 at 10:19 AM, Allen Wirfs-Brock al...@wirfs-brock.comwrote: At the usual place: http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts Changes include: - Made Symbols a primitive type - Added semantics for generator function and generator method definitions - Added semantics for array comprehensions and generator comprehensions - Added semantics for yield and yield* - Replaced StopIteration exception with nextResult objects - Updated for-in/of semantics to use new generator protocol - Made Arrow function and concise method formal parameters “strict” - Added Object.setPrototypeOf function - Made Function constructor subclassable - Added Array.prototype.find and findIndex - Added Math.imul - Added ArrayBuffer.isView to check for ArrayBuffer view objects - Added Clause 15.19 defining the content of the build-in iteration module. Coontains built-ins needed to support generators - Disallow Unicode escapes as RegularExpressionFlags - Moved Object.prototype.__proto__ back to Annex B. It’s a simple access or that is not Realm specific. - Added in Annex B __proto__ property keys in object literals - Added placeholder in Annex B for defining syntax of html-like comments - In Annex B, first cut at block-level function declaration legacy semantics - Added RegExp.prototype.compile to Annexs B - Fixed handling of negative integer indices for typed arrays. Elimiante ToPositiveInteger abstract operation - Typed Arrays are allowed to stre values using native endianess. - Fixed various bugs in class declaration semantics - Dates never expose -0 as a time value - Resolved Bugs: 1469, 1461-1460, 1458, 1452-1451, 1449, 1446, 1442-1435, 1433, 1432-1414, 1411-1407, 1404, 1403-1401, 1399-1397, 1395-1392, 1389-1376, 1374-1366, 1363-1361, 1359, 1357-1355, 1352-1348, 1346, 1344-1342, 1340-1338, 1336-1318, 1316, 1314-1301, 1299-1296, 1294-1291, 1289-1288, 1286-1285, 1284, 1282, 1280-1277, 1272, 1253, 1117 Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Regards, Yusuke Suzuki ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Future feedback
Actually, mutation observers have some special behavior that only lasts until the end-of-microtask queue is empty. If you start observing the mutations that happen in a particular Node subtree rooted in a node A, you will be told about all mutations that happen in the nodes that were descendants of A until all end-of-microtask notifications have fired. So even if a node is removed from A and then modified, the observer is notified about those mutations as long as they happen before all end-of-microtask observers have fired. At least I think that's how I think it works. You'd have to check the spec for more details. Possibly this is something that can be changed though. / Jonas On Tue, May 14, 2013 at 5:59 PM, Mark Miller erig...@gmail.com wrote: AFAICT, the microtask queue is just another output queue, and the strict priority of the microtask queue over other queues is just a policy choice of which outgoing queue to service next. The input queue model could not guarantee strict priority without creating a two level queue. The outgoing queue model keeps this separate with no loss of generality. Cool. On Tue, May 14, 2013 at 5:54 PM, Mark S. Miller erig...@google.com wrote: -- Forwarded message -- From: Mark S. Miller erig...@google.com Date: Tue, May 14, 2013 at 4:54 PM Subject: Re: Future feedback To: Boris Zbarsky bzbar...@mit.edu Cc: David Bruant bruan...@gmail.com, Sean Hogan shogu...@westnet.com.au, Jonas Sicking jo...@sicking.cc, public-script-co...@w3.org public-script-co...@w3.org I see. I was thinking primarily about incoming queues whereas this formulates the issue primarily in terms of outgoing queues. Rather than have a non-deterministic interleaving of events into the incoming queue, which then services them later, this just moves the non-deterministic choice as late as possible, at the point when the next turn is ready to start. This effectively removes the notion of an incoming queue from the model. Curiously, this is how Ken https://www.usenix.org/conference/usenixfederatedconferencesweek/composable-reliability-asynchronous-systems-treating and NodeKen http://research.google.com/pubs/pub40673.html treat the persistent storage of distributed messages. The incoming queues are ephemeral, outgoing messages are not dropped until receipt has been acknowledged, and messages are not acknowledged until processed by a turn that has been checkpointed. On restart a different interleaving may be chosen, which the incoming queue model would have a harder time accounting for. I like it. AFAICT, this is a better way to specify communicating event loops in all ways. Thanks! On Tue, May 14, 2013 at 7:03 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 5/14/13 9:04 AM, David Bruant wrote: http://lists.w3.org/Archives/Public/public-script-coord/2013AprJun/0167.html I should note that the description of the browser event loop in that message is wrong. It does not have only two FIFO queues in the specs, or in implementations. In particular, see task sources. I would be strongly opposed to specifying something that requires only two FIFO queues. -Boris -- Cheers, --MarkM -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Text by me above is hereby placed in the public domain Cheers, --MarkM ___ 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: Future feedback
Is there any reason that this can't be modeled with the end-of-microtask queue still being just one of many output queues? These observed mutations would just queue notifications on the end-of-microtask queue. The interleaving policy would be to always select an event from the end of microtask queue first if it is non-empty. I.e., strict priority, decided at the moment when the next turn is about to be started. Am I missing something? On Tue, May 14, 2013 at 7:08 PM, Jonas Sicking jo...@sicking.cc wrote: Actually, mutation observers have some special behavior that only lasts until the end-of-microtask queue is empty. If you start observing the mutations that happen in a particular Node subtree rooted in a node A, you will be told about all mutations that happen in the nodes that were descendants of A until all end-of-microtask notifications have fired. So even if a node is removed from A and then modified, the observer is notified about those mutations as long as they happen before all end-of-microtask observers have fired. At least I think that's how I think it works. You'd have to check the spec for more details. Possibly this is something that can be changed though. / Jonas On Tue, May 14, 2013 at 5:59 PM, Mark Miller erig...@gmail.com wrote: AFAICT, the microtask queue is just another output queue, and the strict priority of the microtask queue over other queues is just a policy choice of which outgoing queue to service next. The input queue model could not guarantee strict priority without creating a two level queue. The outgoing queue model keeps this separate with no loss of generality. Cool. -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
