On Jul 21, 2014, at 2:35 PM, Ian Hickson wrote: > On Mon, 21 Jul 2014, Allen Wirfs-Brock wrote: >>> > > (Is there a URL that will always point to the very latest version, by any > chance?)
http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts > > >>>> is always initialized (by NextJob) with an empty execution context >>>> stack. >>> >>> What step in NextJob does this? It seems that step 3 asserts it, but >>> step 1 doesn't seem to affect the stack, and step 2 refers to the >>> "suspend" prose, which seems mostly non-normative (I can't quite tell >>> it's normative status -- there's no step-by-step algorithms, which >>> seems to be the way the ES spec indications normativity, but there's >>> no RFC2119-style prose either, so I can't tell the descriptive >>> statements in that section from the prescriptive ones). >> >> It's because NextJob is only supposed to be used within an Job >> initiation abstract operation that is passed to EnqueueJob. So, since >> we start with an empty stack in 8.5 and each job each returns/unwinds to >> its starting context it flows like this >> >> <empty stack> >> create dummy root context >> 8.5 Initialization, does stuff > > The "does stuff" in particular includes step 5, "Push newContext onto the > execution context stack". yes > >> returns/unwinds to dummy root context > > Where? This is largely implicit in the ES spec. algorithm conventions (5.2). Abstract operations call each other in a strict call/return manner. Exceptional control flows (such an ES level throw or return statements) are modeled using completion records (6.2.2) that are returned as values from the abstract operations. The execution context stack (8.3) is used to track ES level function activations/returns but not specification level call/returns from abstract operations. Execution contexts are explicitly pushed on to the context stack by call-related abstract operations and explicitly removed at function boundaries for ES return statements and when propagating "throw" completion records past a ES function call boundary. steps 2-5 of 8.5 establishes the dummy root context, it's the active context when InitializeFirstRealm is performed in step 6. If any thing performed by InitializeFirstRealm happens to create/push additional execution contexts they will be popped by the time we return to step 7 of 8.5. Step 9 is a NextJob macro and step 2 of NextJob suspends the "running execution context" which in this case is the dummy root context created in steps 2-5. (I just added "and remove it from the execution context stack" to the text NewJob step 2 to make it explicit that suspending the running execution context also removes it from the stack. Steps 6-8 then creates a new root execution context for the next job... > >> NextJob, deletes dummy root context > > Where? step 2. > > Step 3 of NextJob says "Assert: The execution context stack is now empty", > but I don't see anything that undoes the effect of 8.5's step 5, which > makes it not empty. I admit I haven't made an exhaustive search of all the > algorithms directly and indirectly called by 8.5. I started trying to > trace all the steps between 8.5:5 and NextJob:3 in this e-mail, but that's > a lot of calls so it's probably not worth including here. Does the text I added to step 2 clear this up? Allen
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
