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().
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