| 09:27 | <Surma> | Can someone add surma@shopify.com to the calendar invite for the recurring Loader meeting? |
| 09:27 | <Surma> | yulia | Out of Office until July 11th: Hope you feel better soon! |
| 16:51 | <littledan> | Surma: Note that you may be able to add the whole TC39 calendar for yourself from https://calendar.google.com/calendar/u/0/embed?src=mozilla.com_l7b50itpaa9bnrvr61nebqrne8@group.calendar.google.com&ctz=America/Los_Angeles |
| 17:19 | <Surma> | Surma: Note that you may be able to add the whole TC39 calendar for yourself from https://calendar.google.com/calendar/u/0/embed?src=mozilla.com_l7b50itpaa9bnrvr61nebqrne8@group.calendar.google.com&ctz=America/Los_Angeles |
| 17:49 | <Kris Kowal> | shu: do we have an alternative facilitator? |
| 17:53 | <Kris Kowal> | I’ve sketched an agenda:
|
| 17:57 | <Kris Kowal> | I believe yulia | Out of Office until July 11th had in mind some important front-matter to get us all on the same page for each other’s hopes and expectations from module harmony, which I think we ought to pursue as early as possible. I can also attempt to facilitate that, though I’m also not confident I can fill Yulia’s shoes. |
| 17:58 | <Kris Kowal> | That is, in fact, probably more important to articulate than any of the above. |
| 17:59 | <Kris Kowal> | To that end, please give me a thumbs up here if you’re prepared to speak to your own hopes and expectations of Module Harmony tomorrow. |
| 17:59 | <Kris Kowal> | Perhaps we can do a round-the-room. |
| 18:02 | <Kris Kowal> | (And of course, I hope any other convener can lead this conversation since I don’t expect anyone to trust my impartiality!) |
| 18:56 | <littledan> | I can help with convening if Yulia is out but at the same time maybe we should just wait until she gets back? |
| 20:27 | <Kris Kowal> | I can help with convening if Yulia is out but at the same time maybe we should just wait until she gets back? |
| 20:28 | <littledan> | I'd like to propose, for an upcoming meeting, a discussion of how we've figured out how a lot of the space factors into three mostly orthogonal proposals (module reflection, module blocks/fragments, and the loader) since I think we made a lot of progress on that in the past couple weeks |
| 20:29 | <Kris Kowal> | Agreed. I’d also like to focus on how the points of intersection appear to be coherent. |
| 20:30 | <littledan> | top agenda item: How do we name ModuleInstance/ModuleBlock :) |
| 20:30 | <Kris Kowal> | I think with some effort over the next week, we could arrive at the harmonious conclusion: Module. |
| 20:31 | <Kris Kowal> | And the desugarring of module {} to new Module(). |
| 20:32 | <littledan> | hmm, maybe. I feel suspicious but I'm fine with that as a working title |
| 20:32 | <Kris Kowal> | It seems likely to me that, even if the notion of a Compartment survives, the notion of a module descriptor probably merges into Module instances. |
| 20:32 | <littledan> | (basically for the reasons you gave in your last presentation) |
| 20:32 | <Kris Kowal> | Yes, rightly suspicious. |
| 20:33 | <Kris Kowal> | Some of my thinking, chronicled above, has changed over the last couple weeks. |
| 20:35 | <Kris Kowal> | Since Caridy’s been challenging my assumption that 262 would need to subsume module maps. Nicolò has also been moving in the direction of subsuming module maps. Not sure whether we’ve crossed positions, but that would be funny. |
| 20:35 | <littledan> | huh, what do you mean by subsuming module maps? |
| 20:39 | <Kris Kowal> | And Nicolò also learned this morning that HTML anchors module maps in an unexpected place: on module instances. That’s surprisingly consistent with what Caridy is proposing. |
| 20:41 | <Kris Kowal> | I mean that module maps are currently implied into existence by 262, through host behaviors. There isn’t a [[ModuleMap]], say, on a Realm record. (Qualifier: this is hearsay. I’m not sufficiently intimate with 262 to purport the non-existence of anything within its pages.) |
| 20:43 | <Kris Kowal> | Caridy’s driving toward a simplification of the compartment proposal that notably omits Compartment. I’m convinced that it’s functionally equivalent, even up to preserving all useful idempotence invariants and compatibility with our hardened JavaScript objectives. Omitting compartments effectively moves all module memoization behavior to a new kind of concrete Module Record, say, Virtual Module Record, which would be reïfied by a new Module constructor. |
| 20:45 | <nicolo-ribaudo> | (note: the specific word in html for module instances is "module scripts") |
| 20:45 | <Kris Kowal> | And I understand that you, Daniel Ehrenberg , provided the useful insight that the importMeta is sufficient to imply a referrer without having a dedicated referrer argument on a Module constructor. |
| 20:47 | <nicolo-ribaudo> | I have to think about this more, but after I talked with you (Kris) I'm convinced that my direction and how I understood Caridy's direction from you are not inconciliabile |
| 20:48 | <nicolo-ribaudo> | Always assuming that compartments/"reified modules" are exactly as much powerful as hosts |
| 20:48 | <Kris Kowal> | My opinion is that, to use the name Module, it must be exceedingly worthy. That is to say, there must never come a time in the evolution of 262 that we reify an object that is worthier of the title or create a class where this particular kind of module is no more special that the others. I believe it meets that criterion iff it turns out that all specialization of modules going forward is sufficiently addressed with new types of Static Module Record. |
| 20:49 | <Kris Kowal> | I have to think about this more, but after I talked with you (Kris) I'm convinced that my direction and how I understood Caridy's direction from you are not inconciliabile |
| 20:50 | <Kris Kowal> | I’m hopeful that they are. |
| 20:50 | <nicolo-ribaudo> | Yes. The things I added in the modules block spec are all "spec internals", and they shouldn't affect the exposed API in any way |
| 20:51 | <littledan> | And I understand that you, Daniel Ehrenberg , provided the useful insight that the |
| 20:51 | <Kris Kowal> | We may have run together. |
| 20:51 | <Kris Kowal> | So I’ll unpack what we learned. |
| 20:52 | <littledan> | (note: the specific word in html for module instances is "module scripts") |
| 20:52 | <nicolo-ribaudo> | Yes, it's the most confusing name possible |
| 20:52 | <Kris Kowal> | Assuming new Module(source, importHook, importMeta) is sufficient, importMeta is not identical to import.meta as seen by the source, but is identical to the object received by importHook to address the referrer, as in importHook(importSpecifier, importMeta) => Promise<Module>. |
| 20:53 | <Kris Kowal> | That is to say, that in user code, one can arrange a side table from importMeta to referrer and it’s sufficient that import hooks know about it. |
| 20:54 | <littledan> | I was thinking about it and... I'm not sure if importHook is at the same level as importMeta. At least, when serializing and deserializing a Module, you'll often preserve the importMeta and swap in a new importHook |
| 20:54 | <littledan> | (along with giving it a new identity) |
| 20:54 | <Kris Kowal> | That allows for the possibility, as is necessarily the case for some environments, that neither import.meta.url and import.meta.resolve are available for an importHook to use, much less necessarily trust. |
| 20:54 | <littledan> | "preserve" importMeta in an abstract sense, though--it will surely be a different object identity |
| 20:55 | <littledan> | That allows for the possibility, as is necessarily the case for some environments, that neither |
| 20:55 | <Kris Kowal> | Yes, importMeta !=== import.meta. |
| 20:55 | <littledan> | oh! really? |
| 20:56 | <Kris Kowal> | I should say, not necessarily ===. |
| 20:56 | <littledan> | now I'm even more confused |
| 20:57 | <Kris Kowal> | What i’m saying is that, for the purposes of this side table, importMeta as given to the constructor may be copied over an Object with a null prototype and all useful properties of import hooks are preserved. |
| 20:58 | <Kris Kowal> | I’m not saying that they can’t be identical. It probably wouldn’t be useful to create a new mechanism that allows import.meta to be a number or a proxy. |
| 20:58 | <Kris Kowal> | One way to do that would be copying properties. Another would just be to assert its nature. Asserting it’s not a proxy is somewhat hard. |
| 21:01 | <Kris Kowal> | hmm, why? import.meta.url, import.meta.resolve, or some other property carries the referrer in another host-defined sort of way. Not all existing environments meet that bar. I’m not suggesting this is a blocker. I’m suggesting that it’s definitely not a blocker. Those environments can be emulated with a side table keyed on importMeta, regardless of whether that’s identical to import.meta. |
| 21:03 | <Kris Kowal> | Which is to say, the problem I imagined with not enshrining referrer in the Module constructor, turns out to be imaginary. |
| 21:03 | <Kris Kowal> | Now, whether the same reasoning applies to module blocks remains mysterious to me. |
| 21:04 | <Kris Kowal> | That is, whether it is sufficient to serialize import.meta when reconstructing an equivalent module in another worker, as opposed to serializing a [[Referrer]] internal slot. |
| 21:05 | <Kris Kowal> | (To the extent that import.meta is serializable!) |
| 21:05 | <nicolo-ribaudo> | But isn't import.meta lazily-initialized (on first access), so potentially not available when transferring a module block? |
| 21:05 | <Kris Kowal> | As written today, yes. |
| 21:06 | <Kris Kowal> | Lazy initialization of import.meta could be copying properties from importMeta. |
| 21:06 | <Kris Kowal> | Regardless, if we relaxed the verbiage around lazy initialization of import.meta, the change wouldn’t be observable. |
| 21:13 | <Kris Kowal> | Bradley related to us at a SES call of yore that Node.js depends on this laziness to avoid instantiating an import.meta.resolve closure for every module. That gets created lazily on the first evaluation of import.meta. In the Compartments proposal, we solved that problem by adding a needsImportMeta property to ModuleSource / StaticModuleRecord instances such that a loadHook / importHook can avoid building an importMeta except for modules that are likely to need it, by reflecting static analysis. |
| 21:14 | <Kris Kowal> | Caridy’s direction preserves that solution. |
| 21:14 | <littledan> | Regardless, if we relaxed the verbiage around lazy initialization of |
| 21:14 | <littledan> | which, probably doesn't exist right now |
| 21:14 | <Kris Kowal> | It might with the experimental Node.js Loader. |
| 21:14 | <Kris Kowal> | I’m inclined to hope that we get ahead of that here. |
| 21:15 | <Kris Kowal> | And if a host virtualization hook is running synchronously during the first evaluation of import.meta, that seems needlessly foot-gunny. |
| 21:19 | <Kris Kowal> | shu, littledan We probably ought to decide and communicate a cancellation for tomorrow’s meeting. Are either of you positioned to reach all participants? |
| 21:20 | <guybedford> | FYI I posted https://github.com/whatwg/html/issues/8077 for making import.meta.resolve a generic resolver |
| 21:20 | <guybedford> | which might be a useful technique for loaders to get access to the global resolver |
| 21:21 | <guybedford> | Kris Kowal: are you referring to the SES or modules meeting tomorrow? Is this because we don't have someone to run it? |
| 21:22 | <Kris Kowal> | Yulia being absent leaves us without a convener, but more importantly, leaves us without an important stakeholder. |
| 21:23 | <guybedford> | It may still be useful to have the discussion if we can |
| 21:23 | <guybedford> | Didn't shu give host credentials to others as well? |
| 21:23 | <guybedford> | Has no one else come forward to assist with convening? |
| 21:23 | <Kris Kowal> | Yes, others can open the meeting. |
| 21:24 | <Kris Kowal> | Dan has come forward to assist with convening if we convene. |
| 21:24 | <guybedford> | Even if we don't have all stakeholders, we should still have notes to share and can continue to build some shared understanding on the matters |
| 21:25 | <littledan> | Didn't shu give host credentials to others as well? |
| 21:25 | <Kris Kowal> | I think there’s a hope that we move forward together. Discussions are obviously great, but we don’t want to assume that the shared context has advanced. |
| 21:26 | <Kris Kowal> | That is, if we have any module harmony conversations outside of these “incubator” calls, we need to expect to present our findings again on the call. |
| 21:27 | <guybedford> | I think we are still very much in a phase of discovery here |
| 21:27 | <Kris Kowal> | This is true. |
| 21:27 | <guybedford> | so that it's less about decisions and more about continuing the conversations |
| 21:27 | <guybedford> | there's still a lot to discuss! |
| 21:27 | <Kris Kowal> | I read you’re in favor of having a conversation. |
| 21:27 | <Kris Kowal> | I’m also very aware that we have two weeks to plenary. |
| 21:28 | <Kris Kowal> | And that I have put my foot into the agenda. |
| 21:29 | <guybedford> | Myself and Luca at least would value giving a 10 minute update on where we would like to take import reflection, and before plenary, to ensure we don't step on any toes |
| 21:29 | <guybedford> | we want to ensure we're getting the cross-concerns right |
| 21:30 | <Kris Kowal> | One option is that I can reconvene the SES meeting. |
| 21:30 | <guybedford> | the hope for these meetings, at least for myself, was to be able to see how the pieces of the puzzle can fit together to form a wholistic picture |
| 21:30 | <Kris Kowal> | Same, agreed. |
| 21:31 | <nicolo-ribaudo> | One option is that I can reconvene the SES meeting. |
| 21:32 | <Kris Kowal> | No, we have an agreement that any findings from the SES meeting will be reprised at the Module Harmony group so that the broader group of stakeholders can stay in sync. |
| 21:32 | <nicolo-ribaudo> | Ok right, it would be good then. I don't think we should come to a "group decision" without all the important stakeholders |
| 21:32 | <Kris Kowal> | We can of course retcon our findings so we’re not presenting the incoherent ideas! |
| 21:33 | <littledan> | Not sure what you mean by "reprised" but yeah as Nicolo says the important thing is that we don't think of anything from SES as having reached a group decision, but instead having had some interesting discovery-oriented discussions |
| 21:34 | <Kris Kowal> | It’s also important that group decisions don’t come out of the modules harmony calls, but I think we’re mostly on the same page 😉 |
| 21:36 | <Kris Kowal> | In any case, I’m going to continue making slides and will expect to share them in one venue or another. |
| 21:36 | <Kris Kowal> | And it would be good for us to communicate a decision. |
| 21:40 | <guybedford> | It would be good to work through the slides further, it would also be good to have a few mins for us each to share our respective updates |
| 21:40 | <guybedford> | we could probably present the current import reflection thinking in about 5 - 10 mins |
| 21:41 | <guybedford> | we are actively seeking feedback |
| 21:42 | <guybedford> | would it be possible to complete the slides in 30-40 mins? |
| 21:42 | <guybedford> | would definitely be useful to continue building out the shared context |
| 21:42 | <guybedford> | or is the problem Kris Kowal that you would prefer to have Yulia present for that? |
| 21:43 | <Kris Kowal> | I intend to present an abbreviated deck from the overflow from the prior meeting. |
| 21:44 | <Kris Kowal> | I think Yulia would have kicked this meeting off with an around-the-room of each of our goals. |
| 21:45 | <Kris Kowal> | I’ve asked Nicolò to show what he’s learned over the last two weeks from writing up spec text for module blocks. |
| 21:45 | <Kris Kowal> | I’d be elated to give you guybedford the floor to sync up on import reflection. |
| 21:46 | <Kris Kowal> | Caridy will miss the first 20', but I’m hoping he gets a chance to share his vision for Module and ModuleSource. |
| 21:47 | <Kris Kowal> | And I think it’s not too premature to share his sketch (cc nicolo-ribaudo) https://gist.github.com/caridy/98f61cf6100243c3cecef5c16a4eff2d |
| 22:12 | <littledan> | Yeah well I'm up to convene/facilitate a discovery-oriented discussion as long as we plan to come back and reconsider things when stakeholders are available |
| 22:13 | <littledan> | so we can do this tomorrow at the time in the calendar if people want to |
| 22:24 | <Kris Kowal> | That at least has the virtue of not requiring last minute comms. |
| 22:24 | <Kris Kowal> | And also an extra half hour of talk time. |
| 22:38 | <Luca Casonato> | I will have to drop off at the top of the hour unfortunately, so it’d be great if we can cover import reflection some time in the first half of the meeting |
| 22:41 | <Kris Kowal> | I’m going to defer my overflow deck to a subsequent meeting. I’m writing Luca Casonato and guybedford into the agenda as the opening act. |
| 22:42 | <Kris Kowal> | Also moved Goals to the next meeting for Yulia. |
| 22:43 | <Kris Kowal> | The agenda is a writable link off the TC39 calendar invitation. |
| 22:45 | <Luca Casonato> | Thanks Kris |