Editorial: GlobalObject cannot be undefined in the GetGlobalObject

[kimjg1119]

The [[GlobalObject]] of the Realm record is an Object or undefined. However, it seems that in GetGlobalObject, the slot cannot be undefined. To make this clear(and resolve some ESMeta alarms), I suggest adding an assertion.

[bakkot]

Thanks for the contribution. However, in practice, this is never actually *undefined* except between steps 4 and 16 of InitializeHostDefinedRealm, which is the thing which initializes Realm Records. So it would be better to instead remove *undefined* from the type and remove the Set realm.[[GlobalObject]] to undefined. step from InitializeHostDefinedRealm.

[jmdyck]

... remove the Set realm.[[GlobalObject]] to undefined. step from InitializeHostDefinedRealm.

So then the running execution context's Realm would be missing a [[GlobalObject]] field between steps 11 and 16. Which is okay because steps 12-15 don't care about the running execution context? (If that's the case, I think I'll submit a PR to move the execution context stuff to the end of InitializeHostDefinedRealm, after the realm has finished initializing.)

[kimjg1119]

So then the running execution context's Realm would be missing a [[GlobalObject]] field between steps 11 and 16. Which is okay because steps 12-15 don't care about the running execution context? (If that's the case, I think I'll submit a PR to move the execution context stuff to the end of InitializeHostDefinedRealm, after the realm has finished initializing.)

Sorry, but I’m a bit confused about this. Does this mean that the type of [[GlobalObject]] is not undefined in step 12-15? I’m aware of issue #3482, and I’m unable to determine the type of this field after the proposed solution is applied.

[bakkot]

@kimjg1119 Whenever we are initializing fields or slots imperatively the type of a field is not necessarily realized until the step which initializes it. Compare, for example, NewGlobalEnvironment: what is the type of _env_.[[VarNames]] at step 5 of that algorithm? The answer is that it doesn't really have one; it hasn't been initialized yet. But nothing refers to it so that doesn't matter.

[kimjg1119]

@kimjg1119 Whenever we are initializing fields or slots imperatively the type of a field is not necessarily realized until the step which initializes it. Compare, for example, NewGlobalEnvironment: what is the type of _env_.[[VarNames]] at step 5 of that algorithm? The answer is that it doesn't really have one; it hasn't been initialized yet. But nothing refers to it so that doesn't matter.

Thanks! I agree that simply removing the initialization step with undefined should be sufficient to resolve the ESMeta alarm, so I’m completely on board with it.

NOTE: We will temporarily put this in esmeta-ignore.json until v0.5.1 since we handle the type system manually; thus ESMeta does not know undefined has been removed.

[bakkot]

This assertion is no longer necessary.