why NextJob?

# Michael Dyck (10 years ago)

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: esdiscuss.org/topic/the-initialization-steps-for-web-browsers#content-9 which (IIUC) still has advantages (a) and (b).

Given the alternatives, why does the spec use NextJob?

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:
https://esdiscuss.org/topic/the-initialization-steps-for-web-browsers#content-9
which (IIUC) still has advantages (a) and (b).

Given the alternatives, why does the spec use NextJob?

-Michael

# Allen Wirfs-Brock (10 years ago)

On May 18, 2015, at 10:17 AM, Michael Dyck wrote:

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:

Call Initialization().

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: esdiscuss.org/topic/the-initialization-steps-for-web-browsers#content-9 which (IIUC) still has advantages (a) and (b).

Given the alternatives, why does the spec use NextJob?

Because that was the design I came up with when I introduced the Job concept into the spec. Obviously, other semantically equivalent designs are possible. Once that spec work was done (a) and (b) are largely irrelevant because the work has already been done and (c) is insufficient reason to redo the work.

On May 18, 2015, at 10:17 AM, Michael Dyck wrote:

> 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:
> https://esdiscuss.org/topic/the-initialization-steps-for-web-browsers#content-9
> which (IIUC) still has advantages (a) and (b).
> 
> Given the alternatives, why does the spec use NextJob?

Because that was the design I came up with when I introduced the Job concept into the spec.  Obviously, other semantically equivalent designs are possible.  Once that spec work was done (a) and (b) are largely irrelevant because the work has already been done and (c) is insufficient reason to redo the work.

Allen

# Michael Dyck (10 years ago)

On 15-05-18 03:09 PM, Allen Wirfs-Brock wrote:

On May 18, 2015, at 10:17 AM, Michael Dyck wrote:

As far as I can see, this has the same semantics as the current spec [..], but it's simpler, since: (a) it doesn't need to introduce NextJob [...] (b) it doesn't need to introduce Job [...]; and (c) it 'explicitizes' the repeatedness of picking a Job Queue and running its front job.

Given the alternatives, why does the spec use NextJob?

Because that was the design I came up with when I introduced the Job concept into the spec. Obviously, other semantically equivalent designs are possible.

Ah, okay, I thought there was some advantage of the NextJob approach (either now, or when it was introduced) that I was missing.

Once that spec work was done (a) and (b) are largely irrelevant because the work has already been done

I find this statement puzzling, given how much time you yourself have spent simplifying work that "has already been done".

In general, I believe that simplification (where possible) is very relevant to the readers of the spec.

On 15-05-18 03:09 PM, Allen Wirfs-Brock wrote:
>
> On May 18, 2015, at 10:17 AM, Michael Dyck wrote:
>
>> As far as I can see, this has the same semantics as the current spec [..], but it's simpler, since:
>> (a) it doesn't need to introduce NextJob [...]
>> (b) it doesn't need to introduce Job [...]; and
>> (c) it 'explicitizes' the repeatedness of picking a Job Queue and running its front job.
>>
>> Given the alternatives, why does the spec use NextJob?
>
> Because that was the design I came up with when I introduced the Job
> concept into the spec. Obviously, other semantically equivalent designs
> are possible.

Ah, okay, I thought there was some advantage of the NextJob approach (either 
now, or when it was introduced) that I was missing.

> Once that spec work was done (a) and (b) are largely irrelevant
> because the work has already been done

I find this statement puzzling, given how much time you yourself have spent 
simplifying work that "has already been done".

In general, I believe that simplification (where possible) is very relevant 
to the readers of the spec.

-Michael

# Allen Wirfs-Brock (10 years ago)

On May 18, 2015, at 2:45 PM, Michael Dyck wrote:

On 15-05-18 03:09 PM, Allen Wirfs-Brock wrote:

Once that spec work was done (a) and (b) are largely irrelevant because the work has already been done

I find this statement puzzling, given how much time you yourself have spent simplifying work that "has already been done".

In general, I believe that simplification (where possible) is very relevant to the readers of the spec.

I'm specifically talking about the ES6 spec. Future simplification or refinement is always possible, particularly as part of new feature work that touches that area

On May 18, 2015, at 2:45 PM, Michael Dyck wrote:

> On 15-05-18 03:09 PM, Allen Wirfs-Brock wrote:
> 
>> Once that spec work was done (a) and (b) are largely irrelevant
>> because the work has already been done
> 
> I find this statement puzzling, given how much time you yourself have spent simplifying work that "has already been done".
> 
> In general, I believe that simplification (where possible) is very relevant to the readers of the spec.

I'm specifically talking about the ES6 spec.  Future simplification or refinement is always possible, particularly as part of new feature work that touches that area

Allen



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150518/5d73db3c/attachment-0001.html>