why NextJob?

Michael Dyck jmdyck at ibiblio.org
Mon May 18 17:17:00 UTC 2015

Can someone explain to me why the spec needs NextJob?

Consider this alternative:
-- Replace every invocation of 'NextJob' with 'Return'.
-- Introduce a top-level abstract operation for them to return *to*:

    1. Call Initialization().
    2. Repeat:
         a-h. [steps 2-9 of NextJob]
         i. Let /result/ be the result of performing the abstract operation
            named by /nextPending/.[[Job]] etc.
         j. If /result/ is an abrupt completion, etc.

As far as I can see, this has the same semantics as the current spec (i.e., 
requires the same behavior from implementations), but it's simpler, since:
(a) it doesn't need to introduce NextJob as a different way for abstract 
operations to terminate;
(b) it doesn't need to introduce Job as a class of abstract operation that 
must call NextJob rather than Return or ReturnIfAbrupt; and
(c) it 'explicitizes' the repeatedness of picking a Job Queue and running 
its front job.

Or, as another alternative, consider Ian Hickson's 'RunCode' suggestion:
which (IIUC) still has advantages (a) and (b).

Given the alternatives, why does the spec use NextJob?


More information about the es-discuss mailing list