why NextJob?

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

why NextJob?

Michael Dyck
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
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: why NextJob?

Allen Wirfs-Brock

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
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: why NextJob?

Michael Dyck
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
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: why NextJob?

Allen Wirfs-Brock

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




_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss