On Jun 10, 2014, at 2:31 PM, Garrett Smith wrote:

> On 6/10/14, Ian Hickson <ian at hixie.ch> wrote:
>> On Tue, 10 Jun 2014, Allen Wirfs-Brock wrote:
> 
> Hi Ian; Allen.
> 
>>> (Also, how could step 6's substeps ever get triggered?)
>>> 
>>> Working backwards, step 5 does many things, some of which are specified
>>> as having error conditions and exceptions, so I have to take into
>>> account what happens if any errors occur. Step 6, just says that if they
>>> do then the startup of the ES environment has failed.  If an implementor
>>> can prove that they [can't] trigger any of those error conditions then
>>> they don't have to worry about it.  But for completeness, I do.
>> 
>> Do you have an example of how any of those steps could fail?
>> 
> 
> I'm guessing that applies for any early error.

Early errors are handled as part of ScriptEvaluationTask http://people.mozilla.org/~jorendorff/es6-draft.html#sec-scriptevaluationtask If an early error is detected the Task competes normally, but without executing any ES code,

> 
> <script>
> var tew;
> continue; // early error; `tew` is not bound.
> </script>
> 
> <script>
> alert(rrq);
> var rrq;
> g; // ReferenceError, not an early error; `rrq` is bound.
> </script>
> 
> 

Everything mentioned below is handled by GlobalDeclarationInstantiation http://people.mozilla.org/~jorendorff/es6-draft.html#sec-runtime-semantics-globaldeclarationinstantiation 
The order in which this occurs for individual scripts is the order in which the corresponding ScriptEvaluationTasks are are enqueued in the "ScriptTasks" queue.  There are different evaluation paths (some of which may still need to be defined) for modules.

Allen


> The following example results in a ReferenceError. Although `gv` is
> defined, that does not occur until the subsequent <script>. After the
> browser has reached the first </script>, the Program is evaluated, and
> at that point, the global Lexical Environment Record does not have a
> `gv` property. Where and how is this behavior described?
> <script>alert(gv); // context to subsequent script is segmented. </script>
> <script>var gv;</script>
> 
> I vaguely remember seeing examples more complex than the example
> above, including dealings with the global scope polluter, and with
> more divergent behavior.
> 
> Moving `gv` to the same script results results in no such runtime
> error, as is explained in ES3.
> <script>
> alert(gv); // contiguous context in same script.
> var gv;
> </script>
> -- 
> Garrett
> @xkit
> ChordCycles.com
> garretts.github.io
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140610/4eedd457/attachment.html>

On Jun 10, 2014, at 2:31 PM, Garrett Smith wrote:

> I'm guessing that applies for any early error.

Early errors are handled as part of [ScriptEvaluationTask](http://people.mozilla.org/~jorendorff/es6-draft.html#sec-scriptevaluationtask) If an early error is detected the Task competes normally, but without executing any ES code,

> ```html
> <script>
> var tew;
> continue; // early error; `tew` is not bound.
> </script>
> 
> <script>
> alert(rrq);
> var rrq;
> g; // ReferenceError, not an early error; `rrq` is bound.
> </script>
> ```

Everything mentioned below is handled by [GlobalDeclarationInstantiation](http://people.mozilla.org/~jorendorff/es6-draft.html#sec-runtime-semantics-globaldeclarationinstantiation). The order in which this occurs for individual scripts is the order in which the corresponding ScriptEvaluationTasks are are enqueued in the "ScriptTasks" queue.  There are different evaluation paths (some of which may still need to be defined) for modules.