TC39 Module Harmony on 2022-06-07

04:29	<Jack Works>	Hello ~
04:53	<Jack Works>	In the current `ThirdPartyStaticModuleRecord` API, the initialize function only receives a `ModuleEnvironmentRecord` (which looks like only containing `import` and `export` bindings). There is no way to access the `globalThis` of the current executing compartment. Lacking this ability make it impossible to compile a ES Module into a `ThirdPartyStaticModuleRecord`.
05:17	<Kris Kowal>	For folks tuning in, Jack is trying to build a no-eval shim for Compartments that precompiles ESM into a bundle.
05:18	<Kris Kowal>	I assume you’re aware that third-party static-module-records can’t emulate live bindings.
05:19	<Kris Kowal>	Jack Works: Have you looked at https://github.com/endojs/endo/blob/master/packages/compartment-mapper/src/bundle.js
05:20	<Kris Kowal>	That uses the SES shim’s static module record to create a bundle. It’s not a complete implementation, but it might be similar to your approach.
05:20	<Jack Works>	I assume you’re aware that third-party static-module-records can’t emulate live bindings. I'm aware that it cannot get the globalThis of the current compartment (it didn't pass as an argument in the initialize function)
05:21	<Kris Kowal>	Yes. My point was tangential to that concern.
05:21	<Kris Kowal>	I imagine we could thread globalThis into the initialize options bag.
05:22	<Kris Kowal>	I’m not entirely sure why it’s necessary for your implementation.
05:22	<Jack Works>	For example, I write `Math`.
05:22	<Kris Kowal>	Oh, I see.
05:23	<Jack Works>	I need to look it up in the current compartment's globalThis
05:23	<Kris Kowal>	Thanks, I understand. The crux of the issue is that static module records must be reusable between compartments, and the global environment varies from initialization to initialization.
05:23	<Jack Works>	And those unresolved global variable lookup should be per-compartment
05:23	<Kris Kowal>	So, indeed, we should thread globalThis into the initializer.
05:25	<Jack Works>	I previously understand ModuleRecordEnvironment as "an exotic object that is a reification of 'lexical scope(import export bindings) and dynamic scope (globalThis)"
05:25	<Jack Works>	But you just clarified that Module environment record does not contain globalThis so I need a new mechanism for this
05:26	<Kris Kowal>	That is certainly a reasonable design and I’m open to entertaining the idea still. I will make a point to ask Moddable for a clarification about what they did in XS.
05:27	<Kris Kowal>	But otherwise, whether or not to have module environment record capture global environment record is something we will want engine vendors to motivate.
05:32	<Kris Kowal>	Oh, module environment record mustn’t capture global environment record, because that includes top-level declarations of Script eval. Modules aren’t supposed to see those.
05:33	<Kris Kowal>	So either module environment record needs to fall through to properties of globalThis, or we need to thread globalThis into the module initializer.
05:33	<Kris Kowal>	Again, either way is fine with me.
05:34	<Kris Kowal>	And I’ll make a note in the proposal README refresh PR.
05:34	<Jack Works>	Aren't decls created in Script either eval-by-eval or on globalThis?
05:34	<Kris Kowal>	Yes, that’s true most of the time. 262 does not currently specify the behavior of REPLs.
05:34	<Kris Kowal>	But REPLs persist the “global contour” between evals.
05:35	<Jack Works>	Oh I didn't notice REPLs. Does that specified in the language? I thought it was made by implementation for debugging
05:35	<Kris Kowal>	That’s not something I hope to address in Draft 1 but expressly supporting the REPL case in the language would be an obvious thing to add to Compartment.
05:35	<Kris Kowal>	It’s not specified in the language.
05:38	<Jack Works>	I'm ok with either, but in a normal ES module, if you import x, then you no longer be able to refer to the global x (globalThis.x is not a direct refer). So if we want to have binding shallow behavior, or you still want to have globalLexicals in the API, I guess making it all in one object will be easier.
05:42	<Kris Kowal>	globalLexicals would be analogous to globalContour. The former applies to modules only, the latter to scripts only. I haven’t added globalLexicals to the proposal yet, and might not until we discuss the layering of Lockdown. globalLexicals have a very limited use, and we found a way to avoid it for now at Agoric. That is, metering guest code.
05:44	<Kris Kowal>	But your hint is good. If we did have globalLexicals, having the module environment record reflect the entire top of stack would be more desirable.
05:45	<Kris Kowal>	I think that convinces me that we should put the burden on the module environment record.
16:21	<Kris Kowal>	(Aside: Moddable’s invention of “module descriptors” is truly wonderful in simplifying the Compartment API. We’ve been able to remove the `compartment.module` method and the `moduleMapHook`.)