On Tue, 10 Jun 2014, Allen Wirfs-Brock wrote:
> 
> By an ECMAScript Environment (and this is what Ecma-262 defines, 
> although it doesn't actually use that name) I mean a heap of ECMAScript 
> objects (and related values) that may directly reference (point to) each 
> other and a single thread of execution of ECMAScript code.  The 
> environment may include multiple "global objects".

Ok. Sounds like that mays to an event loop, on the HTML side.

That should be quite workable. I'll invoke 8.5 when I create an event loop 
(with zero scripts), and I'll invoke CreateRealm() and then 8.5.1 when I 
create a Window.


> > There's not really a "first" Window from the point of view of the HTML 
> > spec. I'm not sure how an initial Realm would really map to a browser.
> 
> I suppose, "first Window" could literally mean the first window opened 
> by a browser.

There might not be one. There's nothing stopping a browser from spawning 
multiple Windows at once on startup, or, indeed, from restoring old state 
all the way down to restoring a pre-existing Web page and JS environment. 
But that's ok, I think if we define things in terms of when the event loop 
is created, it should work out.


> However, a browser like FF that uses JavaScript to implement its chrome 
> might start up a Chrome Realm as its first Realm.

That part of Firefox is an implementation detail; from HTML's point of 
view, it doesn't exist. There should not be any way to distinguish (and 
therefore there should not be anything in the specs that would 
distinguish) a browser that uses JS under the hood and one that doesn't.


> >> I would imagine you would maintain your own queues and dependency 
> >> algorithms that track order and DOM update dependencies such as 
> >> between the two script tags in your example. You would then only 
> >> EnqueueTask a ScriptEvaluationTask when it DOM update dependencies 
> >> has been satisfied.
> > 
> > Well, we want to make sure that browsers only have one dependency 
> > algorithm, we wouldn't want to have redundancy there. See the 
> > "Integrating the Webs' dependency systems" thread from a few weeks 
> > back. I'm trying to understand how ES6's loading logic works so that I 
> > can figure out how to integrate or extend it to handle the more 
> > elaborate needs of other parts of the Web platform, so that we can 
> > e.g. have image loading handled by the same logic as module loading, 
> > since they need to share network resources, can have 
> > interdependencies, etc.
> 
> We may have some chicken and egg issues to work through.

Don't we always!


> But, in general the ES spec. only needs to address the semantic issues 
> of things it defines.  For example, it cares about the relative ordering 
> of Promise Tasks because that is part of the ES promise emantics.  But 
> it doesn't care about the relative ordering of individual PromiseTasks 
> and future cript evaluation tasks because there are no defined semantic 
> dependencies between those.  However, as we move more semantics into ES 
> (for example, event callbacks and timeouts are likely future additions)  
> we will probably have more dependencies to specify.

Sure. But browsers want to make sure they only implement one dependency 
mechanism, and so we have to make sure that all the dependency systems we 
specify can be implemented in terms of a single mechanism. Whether we end 
up doing this by speccing it as one, or speccing it as one that calls out 
to another, or whatever, remains to be seen. At this point I'm just trying 
to learn all I can about the various mechanisms.


> At our latest TC39 meeting we decided to use the term "Job"  for what we 
> had been calling "Task" in the ES spec. Specifically to avoid confusion 
> with the HTML spec.

Cool.


> Basically, what you should do is use ES Jobs as the mechanism for saying 
> here is a bit of ES code that needs to be executed 
> before/after/independently from some other bit of code. But the actual 
> criteria for deciding to make such a request needs to be in your spec.

Right.


> > It seems to me that if step 6 triggers, the whole scripting engine has 
> > failed to start up, which seems like it should be something that is 
> > non-conforming. :-)
> 
> Exactly, the spec. essentially says that if exceptions occur during 
> start-up then a conforming implementation must terminate.  If we said 
> nothing then an implementation might not check for such exceptions and 
> could start ES code execution with in incompletely initialized set of 
> global bindings.

I think ES should just say that an implementation must not fail on 
startup. But that's a separate topic. :-)


> > NextTask seems like it is somewhat redundant with the HTML event loop 
> > mechanism. Ideally I think I'd like to have the hooks set up so that 
> > when a task completes on the ES side, it just returns to the HTML 
> > event loop, which then does its stuff, and eventually calls back into 
> > the ES spec to run the next script.
> 
> That's pretty much what NextTask is.  Steps 1-3 cleans up after the just 
> completed task. Steps 4-5 calls out to the host provided task scheduler. 
> Steps 6-10 initiates execution of the task that was selected by the 
> host.  Step 9 is an extra hook that allow the host environment to do 
> additional host-spec processing for each task immediately before it is 
> executed.

Right, but what I'm saying is that from an editorial perspective it would 
be simpler for host specs to hook into the ES spec, and would be easier 
for implementors to understand, if the loop was turned inside-out from 
what it is now.

Instead of the ES spec having an algorithm that works like this:

   NextTask result:
     handle problems arising from the last job (result)
     stop running code
     get more code to run
     start running code (eventually calls NextTask)

...it would be easier if it was:

   RunCode (code):
     start running code
     stop running code
     let result be the result of running the code
     handle problems arising from the last job (result)
     return to calling algorithm in host spec

...where RunCode is called by the host spec to run code.


On a related note, it would be easier if algorithms that said to "Perform 
any implementation or host environment defined processing" named the 
specific steps. For example, in EnqueueTask step 7, it could say "Perform 
any implementation- or host-environment-defined processing of /pending/ to 
*queue a new task*", where "queue a new task" is a magic phrase (hook) 
that I would then be able to reference in HTML, e.g. by saying "When the 
ES spec says to *queue a new task*, follow these steps...".

Cheers,
-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

On Tue, 10 Jun 2014, Allen Wirfs-Brock wrote:
> By an ECMAScript Environment (and this is what Ecma-262 defines, 
> although it doesn't actually use that name) I mean a heap of ECMAScript 
> objects (and related values) that may directly reference (point to) each 
> other and a single thread of execution of ECMAScript code.  The 
> environment may include multiple "global objects".

Ok. Sounds like that mays to an event loop, on the HTML side.

That should be quite workable. I'll invoke 8.5 when I create an event loop 
(with zero scripts), and I'll invoke CreateRealm() and then 8.5.1 when I 
create a Window.

> I suppose, "first Window" could literally mean the first window opened 
> by a browser.

There might not be one. There's nothing stopping a browser from spawning 
multiple Windows at once on startup, or, indeed, from restoring old state 
all the way down to restoring a pre-existing Web page and JS environment. 
But that's ok, I think if we define things in terms of when the event loop 
is created, it should work out.

> However, a browser like FF that uses JavaScript to implement its chrome 
> might start up a Chrome Realm as its first Realm.

That part of Firefox is an implementation detail; from HTML's point of 
view, it doesn't exist. There should not be any way to distinguish (and 
therefore there should not be anything in the specs that would 
distinguish) a browser that uses JS under the hood and one that doesn't.

> We may have some chicken and egg issues to work through.

Don't we always!

> But, in general the ES spec. only needs to address the semantic issues 
> of things it defines.  For example, it cares about the relative ordering 
> of Promise Tasks because that is part of the ES promise emantics.  But 
> it doesn't care about the relative ordering of individual PromiseTasks 
> and future cript evaluation tasks because there are no defined semantic 
> dependencies between those.  However, as we move more semantics into ES 
> (for example, event callbacks and timeouts are likely future additions)  
> we will probably have more dependencies to specify.

Sure. But browsers want to make sure they only implement one dependency 
mechanism, and so we have to make sure that all the dependency systems we 
specify can be implemented in terms of a single mechanism. Whether we end 
up doing this by speccing it as one, or speccing it as one that calls out 
to another, or whatever, remains to be seen. At this point I'm just trying 
to learn all I can about the various mechanisms.


> At our latest TC39 meeting we decided to use the term "Job"  for what we 
> had been calling "Task" in the ES spec. Specifically to avoid confusion 
> with the HTML spec.

Cool.


> Basically, what you should do is use ES Jobs as the mechanism for saying 
> here is a bit of ES code that needs to be executed 
> before/after/independently from some other bit of code. But the actual 
> criteria for deciding to make such a request needs to be in your spec.

Right.

> Exactly, the spec. essentially says that if exceptions occur during 
> start-up then a conforming implementation must terminate.  If we said 
> nothing then an implementation might not check for such exceptions and 
> could start ES code execution with in incompletely initialized set of 
> global bindings.

I think ES should just say that an implementation must not fail on 
startup. But that's a separate topic. :-)

> That's pretty much what NextTask is.  Steps 1-3 cleans up after the just 
> completed task. Steps 4-5 calls out to the host provided task scheduler. 
> Steps 6-10 initiates execution of the task that was selected by the 
> host.  Step 9 is an extra hook that allow the host environment to do 
> additional host-spec processing for each task immediately before it is 
> executed.

Right, but what I'm saying is that from an editorial perspective it would 
be simpler for host specs to hook into the ES spec, and would be easier 
for implementors to understand, if the loop was turned inside-out from 
what it is now.

Instead of the ES spec having an algorithm that works like this:

```
   NextTask result:
     handle problems arising from the last job (result)
     stop running code
     get more code to run
     start running code (eventually calls NextTask)
```

...it would be easier if it was:

```
   RunCode (code):
     start running code
     stop running code
     let result be the result of running the code
     handle problems arising from the last job (result)
     return to calling algorithm in host spec
```

...where RunCode is called by the host spec to run code.


On a related note, it would be easier if algorithms that said to "Perform 
any implementation or host environment defined processing" named the 
specific steps. For example, in EnqueueTask step 7, it could say "Perform 
any implementation- or host-environment-defined processing of /pending/ to 
*queue a new task*", where "queue a new task" is a magic phrase (hook) 
that I would then be able to reference in HTML, e.g. by saying "When the 
ES spec says to *queue a new task*, follow these steps...".