TC39 Delegates on 2022-06-08

14:22	<Michael Ficarra>	so are we using the Igalia or the 8x8 Jitsi today? Rob Palmer ryzokuken
14:23	<ryzokuken>	Igalia
14:23	<Michael Ficarra>	k please comment on https://github.com/tc39/Reflector/issues/430
14:23	<ryzokuken>	I suppose I could test if 8x8 has gotten better, but there's no way to load test without wasting everyone's time
14:27	<Jack Works>	Can we have this item first if it is possible? `60m \| Import Reflection status update & discussion \| Guy Bedford & Luca Casonato`
14:27	<ryzokuken>	Let me check Jack Works
14:28	<Luca Casonato>	Works for me, but I am not sure if Guy is going to be there yet
14:29	<Luca Casonato>	And he really needs to be there
14:30	<ryzokuken>	Luca Casonato: could you ask Guy about their availability?
14:48	<Kris Kowal>	I also would like to be there. Accelerating baby feeding. :-)
14:55	<ljharb>	looks like it won't let anyone into the igalia jitsi until the "conference has started"? can we start that so people can join early?
14:59	<Rob Palmer>	We are starting plenary in 1 minute on the Igalia server
15:07	<ljharb>	hm, jitsi just booted me out; i had to completely disconnect and reconnect before it would let me back in
15:24	<HE Shi-Jun>	TS erases the `this` parameter currently. Some of these runtime semantics would actually be in conflict with TS (i.e., potentially disallowing `new F()`). TS already report error if `F` is declared as `F(this: X)`, so I don't understand how it could conflict with TS...
15:24	<Bradford Smith>	It strikes me that all the examples of regex patterns with catastrophic backtracking in this presentation are very contrived, doing things it would be very strange for a human to write, like `/(a+)*/`. Anyone know a good realistic case?
15:25	<Justin Ridgewell>	My old manager DOS'd all of Google with a catastrophic backtrack
15:27	<HE Shi-Jun>	oh, static methods with this is a bit weird? to me? Yeah, it's weird, and easy to forget and make mistake. So `static foo(this) {}` at least self-document the weirdness and can protect the users if have proper runtime semantic.
15:27	<Bradford Smith>	I ask more with the idea of making the motivation of the proposal stronger than as an objection.
15:29	<Justin Ridgewell>	cl/27372225
15:29	<HE Shi-Jun>	If TS emits `function f(this) {}`, it will fail when there is no `this` But if TS emits `function f() {}`, it require TS to emit different code based on the type If we have optional syntax `param?` also in JS (type annotation proposal has that syntax), we could solve that. Another option is allow `f(this = defaultValue)`.
15:34	<HE Shi-Jun>	that seems like circular reasoning. this is clearly widening the gap That's why we at least need to explore the area (this is what stage 1 means? isn't it?), to figure out how we can narrow the gap. It's not easy, for example, TS and flow use same syntax but may be have different behavior in some edge cases. But we can't know it before we have the chance to put it on the table.
15:36	<Michael Ficarra>	I kind of wish we had added support for atomic groups BEFORE making that decision about `\p` atomicity
15:36	<Michael Ficarra>	because if this proposal fails to advance, what do we even do?
15:37	<Justin Ridgewell>	Atomic groups aren't necessary for atomic behavior, they just make it more approachable
15:37	<Justin Ridgewell>	`/(?=(foo))\1/` is atomic
15:37	<shu>	That's why we at least need to explore the area (this is what stage 1 means? isn't it?), to figure out how we can narrow the gap. It's not easy, for example, TS and flow use same syntax but may be have different behavior in some edge cases. But we can't know it before we have the chance to put it on the table. i'm not convinced atm of how any solution in the space of adding `this` as a parameter in plain JS can narrow the gap
15:39	<Justin Ridgewell>	https://blog.stevenlevithan.com/archives/mimic-atomic-groups
15:41	<rbuckton>	`/(?=(foo))\1/` is atomic I have a backup slide in the deck that talks about this as well.
15:42	<HE Shi-Jun>	rbuckton: I think you misunderstood my point. `(class {})()` fails in the same way. That's ok. What I don't like is a Function (with a regular `call` on its prototype) for which `f()` and `f.call(undefined)` have different behavior. It's just one of the option, we could also make it still same behavior, aka. `f.call(undefined)` throw. Though it would need `this=defaultValue` or `this?` syntax to allow `undefined` cases. I don't have the strong opinion on that.
15:49	<littledan>	Related thread about parameters to pass to import: https://github.com/whatwg/html/issues/7976
15:53	<littledan>	I think something like this module reflection would be needed if we want to expose the Wasm component model to JS/the web in a consistent way. But I don't know if it's all worth it; maybe the component model is more of a Wasm-on-the-server-only thing.
15:54	<shu>	littledan: what are you imagining in the hypothetical that component model never materializes? have the "default" representation of wasm modules be the WebAssembly.Module instead of an instance?
15:55	<littledan>	I think the default model should be what the Wasm/ESM integration proposal is right now
15:55	<Jack Works>	What's the relationship of current presenting SourceTextModule with StaticModuleRecord in the compartment proposal?
15:55	<littledan>	but I've apparently missed a lot of conversation about this topic and I need to catch up
15:55	<shu>	littledan: that's an Instance, which is not useful at all
15:55	<shu>	because of the custom imports / type marshalling wrapping currently needed
15:55	<littledan>	hmm, could you elaborate on "not useful at all"?
15:57	<Rob Palmer>	but I've apparently missed a lot of conversation about this topic and I need to catch up I was surprised that some folk wanted the default integration to give the Wasm Module, rather than the evaluated instance. Still not sure why.
15:57	<shu>	the short of it is that currently, the way wasm modules are instantiated require both 1) exports be wrapped with type-marshalling wrappers for e.g. strings and such and 2) custom imports from the outer global be passed into the wasm module
15:57	<littledan>	I can understand the argument that Wasm/ESM integration should wait for other things to come through, but CSP seems like a somewhat narrow motivation for this whole proposal (especially since, last time I checked, browsers hadn't bothered to agree with each other on how Wasm CSP works at all)
15:57	<shu>	neither of those things are possible to do in the current ESM integration proposal
15:57	<shu>	so while you can a WebAssembly.Instance out, it's not "useful" in that you have "raw" interfaces
15:58	<littledan>	yeah what I'm missing here is what the motivation is for doing any ESM integration; will it actually help current tooling? this is something I need to understand better, but a bit of a tangent from this presentation
15:58	<shu>	meaning, the hunch is that the current ESM integration proposal won't be used at all, and people will continue to do programmatic fetching and instantiation anyway
15:58	<shu>	ah, yeah that's a bit of a tangent
15:59	<littledan>	meaning, the hunch is that the current ESM integration proposal won't be used at all, and people will continue to do programmatic fetching and instantiation anyway sure, I can understand that argument more easily than "we need ESM integration that gives uninstantiated modules"
15:59	<shu>	my take on that is just like, the ESM module graph is the mechanic we have to tie an app together, it has nice static analyzability properties, so on and so forth
15:59	<shu>	so it'd be a philosophical good to integrate wasm into it
15:59	<shu>	i don't know if there's a pressing need anywhere
15:59	<shu>	since, you know, the imperative way obviously works
16:00	<shu>	but i do think it's important to try to not keep saying "just keep doing everything imperatively"?
16:00	<littledan>	IMO passing in the imports dictionary manually is still doing everything imperatively
16:00	<shu>	well, at least the static import site itself is visible now?
16:01	<Justin Ridgewell>	since, you know, the imperative way obviously works The imperative way is painful
16:01	<Justin Ridgewell>	How do you interop between browsers and node?
16:01	<shu>	i agree
16:02	<shu>	also a previous mistake here is overindexing on the wasm use case, i think guy will go into the asset stuff later
16:05	<littledan>	IMO import(reflectedModule) should link it into the main module graph
16:06	<littledan>	this is basically how it works with module blocks
16:06	<littledan>	and presumably module blocks are the same thing as reflected modules, right?
16:06	<littledan>	(and these are also the same kind of thing as uninstantiated Wasm modules)
16:07	<Mathieu Hofman>	They all sound like StaticModuleRecord from the Compartment proposal
16:07	<littledan>	agreed
16:08	<shu>	i missed the earlier slides about how the `SourceTextModule` and `ModuleInstance` interfaces actually wrap `WebAssembly.Module` and `Instance` (and module blocks)
16:08	<littledan>	I think ModuleInstance is an actual instance, which then you imperatively instantiate
16:08	<Mathieu Hofman>	(if anyone looking at the Compartment proposal, there is an open PR to drastically update / simplify it)
16:09	<littledan>	I'm a big fan of that PR
16:09	<Jack Works>	They all sound like StaticModuleRecord from the Compartment proposal +1 to me. but not exactly the same
16:09	<littledan>	they may be different concrete classes but all of the same spec-internal protocol/contract
16:10	<littledan>	do you agree Jack Works ?
16:10	<Jack Works>	yeah
16:10	<Jack Works>	I'm wondering, current presenting API (manually link module stuff) looks even much lower-level than compartment, what can devs benefits from this
16:10	<littledan>	asset references seem really important on the web to enable prefetching!
16:12	<shu>	wait what do stage 2 reviewers do
16:12	<Mathieu Hofman>	FYI we're planning to have Luca and Guy over in the SES meeting on 06/22 to chat about overlap between these proposals.
16:12	<Jack Works>	we need a cross-proposal API for StaticModuleRecord/SourceTextModule stuff
16:13	<littledan>	we need a cross-proposal API for StaticModuleRecord/SourceTextModule stuff yes and module blocks and WebAssembly.Module
16:14	<littledan>	asset references on JS modules can stand for things which may be dynamically imported later, and should maybe be prefetched
16:15	<littledan>	passing in the dictionary of imports is something that both this proposal and compartments and the Wasm JS API have to do
16:17	<Mathieu Hofman>	we need a cross-proposal API for StaticModuleRecord/SourceTextModule stuff We plan on doing a non-normative refactor of the spec to address that
16:17	<littledan>	I read this comment referring to a JS-exposed API
16:18	<Mathieu Hofman>	Right, but as a first step, we need a definition of what it would be we're exposing. The spec currently conflates the static and instance bits of a module
16:18	<Jack Works>	We plan on doing a non-normative refactor of the spec to address that In the ecma262 directly?
16:18	<littledan>	Right, but as a first step, we need a definition of what it would be we're exposing. The spec currently conflates the static and instance bits of a module Ah, yes, good point, that refactoring would be great
16:19	<littledan>	such a messy part of the spec too!
16:19	<littledan>	it should be much more readable then
16:20	<Jack Works>	let me rejoin
16:21	<Kris Kowal>	(if anyone looking at the Compartment proposal, there is an open PR to drastically update / simplify it) https://github.com/tc39/proposal-compartments/pull/46
16:22	<littledan>	Should we start a discussion group to talk about module loading? Seems like there's a lot going on.
16:22	<Kris Kowal>	FYI we're planning to have Luca and Guy over in the SES meeting on 06/22 to chat about overlap between these proposals. Agenda for June 22 https://docs.google.com/document/d/1FZ95-NZIQE9fw3A8Sgcz2BKep6MlC_Kng0dlf1ehabQ/edit#
16:22	<ryzokuken>	maybe a good idea to do an incubation call on?
16:22	<littledan>	I think we're beyond that and should have like a weekly discussion (maybe this should just be the SES call)
16:23	<ryzokuken>	ah, fair
16:25	<Kris Kowal>	I’m reserving the weekly SES Strategy call for module loading topics through July plenary and all interested parties are welcome.
16:26	<Jack Works>	I wondering why yulia and shu give support 👀 I though from the engine perspective, they don't want to reify the low level mechanism because it blocks the optimization but why this proposal has support from engine side
16:27	<ryzokuken>	was a link to these slides shared at some point?
16:27	<Mathieu Hofman>	Still stays TBD in agenda
16:27	<yulia>	I wondering why yulia and shu give support 👀 I though from the engine perspective, they don't want to reify the low level mechanism because it blocks the optimization but why this proposal has support from engine side I am supporting because it makes deferred module evaluation much easier, and is also necessary for WASM
16:28	<shu>	Jack Works: not sure what optimizations you had in mind there. i'm in support in that the use cases are very important
16:28	<ryzokuken>	yeah, I just double-checked there. Wondering if they sent it someplace else, but probably not.
16:28	<yulia>	I have some concern, i had a counter proposal to my deferred module evaluation that looked like this
16:28	<yulia>	but exposing the module loader API may be error prone
16:28	<shu>	in general i'm against exposing low-level hooks that can fundamentally change assumptions of how certain mechanisms should work, like loading and linking
16:28	<yulia>	this is what held me back, but its interesting to see this get a positive response from the committee
16:29	<littledan>	well, apparently the Wasm JS API, which gives you control over imports, was OK
16:30	<shu>	but also yeah, +1 to yulia, it's not that i have no concerns around the API part of this proposal, but guy has repeatedly said their proposal is just about the "mechanic of reflection"
16:30	<shu>	so i took that to mean the API parts are exploratory, needed to be unified with other proposals, etc
16:30	<Kris Kowal>	The compartments proposal don’t leave `link` or module instance creation to the user and loses no expressivity, for what it’s worth.
16:31	<shu>	sounds like discussions to me, unless you're saying the compartments design is now set in stone?
16:31	<Kris Kowal>	And in turn, answers the question about threading the global environment record and compartment-scoped evaluators, compartment-scoped dynamic import, to the execution of the module.
16:32	<Kris Kowal>	Discussions for sure!
16:32	<Kris Kowal>	It’s set in stage 1 which leaves a great deal of mutability.
16:34	<ljharb>	Justin Ridgewell: re your queue item, because reflection things aren't assertions about the module, and because there's value in keeping assertions and reflections separate
16:34	<Justin Ridgewell>	I think there's only complication for users.
16:35	<Justin Ridgewell>	This slide could easily have been `assert { type: 'asset-reference' }`
16:35	<ljharb>	the module isn't an asset reference tho. assertions are about the module. reflections are about the importer.
16:35	<bakkot>	i don't want to enter the queue but I object to the notion that we should be limiting syntax because bundlers will abuse it
16:36	<bakkot>	bundlers will abuse whatever they want
16:36	<bakkot>	they already abuse comments
16:36	<bakkot>	this should not be a driving concern
16:36	<ljharb>	bundlers won't violate the spec tho
16:36	<bakkot>	the claim was that they would
16:36	<littledan>	they already abuse comments yes, for example, for preloading dynamic imports!
16:36	<ljharb>	ah, maybe i missed the claim
16:37	<ljharb>	(also imo that's not an abuse of comments, that's a fine use of them)
16:37	<Jack Works>	they already abuse comments do you mean this kind of thing? `import(/* webpackIgnore: true */ 'spec')`
16:37	<littledan>	bundlers won't violate the spec tho Yeah I agree, we've seen a lot of interest from all sorts of tooling in following the spec. It's probably weird plugins that would violate it.
16:37	<Justin Ridgewell>	I violate the spec with my build step constantly
16:38	<Rob Palmer>	Me too. ljharb hates it.
16:38	<ljharb>	individuals or tools can violate the spec all they want, but things that violate it are unlikely to gain ecosystem adoption, which is good
16:38	<bakkot>	i don't think that's true, TS "violates the spec" but has plenty of adoption
16:38	<littledan>	individuals or tools can violate the spec all they want, but things that violate it are unlikely to gain ecosystem adoption, which is good Agreed. We have more sway than we might think!
16:39	<ljharb>	many, many times in my experience a debate in node or bundlers has been settled by pointing to a line in the spec that disallows something
16:39	<Mathieu Hofman>	What is the difference between `as "asset-reference"` and `as "module"` ? Conceptually aren't they both the static representation of the asset? Would something like `import static foo from './foo.js'` and `import static foo from './foo.png' assert { type: "png" };` not work?
16:39	<Jack Works>	individuals or tools can violate the spec all they want, but things that violate it are unlikely to gain ecosystem adoption, which is good Babel be like: iterableIsArray 🤣🤣🤣🤣
16:39	<ljharb>	similarly, my experience tells me that anything permitted will be done, and so it is always in our best interest to forbid as much as possible outside of our intended use cases.
16:40	<ljharb>	in an env without symbols, there's no spec to govern iteration :-p that's a place where caveats/shortcuts like that can be reasonable.
16:41	<Kris Kowal>	For the purposes of declaring a dependency statically with the intention to manually link it, `import defer 'x.wasm'` is sufficient.
16:41	<Kris Kowal>	(strawman, clearly)
16:41	<Jack Works>	in an env without symbols, there's no spec to govern iteration :-p that's a place where caveats/shortcuts like that can be reasonable. people adopting loose mode instead of spec semantics even they have `Symbols` or other stuff because it emits shorter/faster code
16:41	<ljharb>	sure. but then they're explicitly choosing to violate the spec. there's a reason babel changed the defaults to be strict.
16:43	<Kris Kowal>	Then as strawmanèd, `new Compartment({ someFlagHere }).import('x.wasm')` to execute later, possibly multiple times.
16:44	<yulia>	Kris Kowal: compartments are fully separate from the current context is that right?
16:44	<yulia>	so, for example, you wouldn't be able to do lazy loading via compartments?
16:45	<Jack Works>	Then as strawmanèd, `new Compartment({ someFlagHere }).import('x.wasm')` to execute later, possibly multiple times. you have load hook, to "execute later". have no idea about execute multiple times
16:45	<Jack Works>	so, for example, you wouldn't be able to do lazy loading via compartments? if we don't have your lazy module in the language, I guess it will also not be possible in the compartment
16:46	<yulia>	ok, thanks for clarifying, i wasn't sure if things had progressed in a new direction than what i remembered from the compartments proposal
16:50	<littledan>	`as "readonly"` certainly sounds like a very different use case. If we wanted to unify everything into a string, we could've done that with import assertions as well.
16:51	<Jack Works>	are we going to have a ses call right now?
16:52	<Mathieu Hofman>	Nope not today
16:52	<Kris Kowal>	so, for example, you wouldn't be able to do lazy loading via compartments? We’re focusing the scope of compartments on module loading and building a bigger tent. To that end, I’m proposing the more generally useful mode of compartments shares the global environment record with the host compartment (albeit the invisible initial compartment that we factor out of the realm)
16:53	<Kris Kowal>	That of course leaves us an open door for Compartmetns-after-Lockdown, which would have isolated globals.
16:53	<littledan>	for better or worse, it feels like we're back at the Loader API. But I feel like it is going to happen this time.
16:53	<bakkot>	I'm not going to capture this scheduling updating in the notes unless someone really wants it
16:53	<yulia>	I feel like a Loader API could work, this might be the basis
16:54	<shu>	i think the core thing insight for me recently is that like 80% of what people want is static specifier resolution to tie their app together. we don't have one, but we do have ESMs, and here we are
16:55	<littledan>	I feel like a Loader API could work, this might be the basis this all is the loader API; I don't think there's a separate thing that needs to come after this whole batch of proposals
16:56	<Kris Kowal>	Yes, being able to express the dependency graph statically, and benefit from resolution at runtime, has always been a huge draw.
16:56	<littledan>	an important thing when importing references to modules is whether the inner modules they import should be interpreted as URLs to (pre)fetch. Fully reflected modules mean "not necessarily" but often you want this to be a yes
16:57	<Kris Kowal>	And frustrating when we get to the edges. CSS imports, for example.
16:57	<Jack Works>	I think the first step is to specify a reified Module Record that works for alllllll those proposals `import x from 'spec' as 'module` and `module { source text }` will return a Module Record Compartment and dynamic import will consume the module record should work with WASM import too `new ModuleInstance(record)` is a fresh way to consume module records I see from the today's presentation should be able to create module record without parsing source text (ThirdPartyStaticModuleRecord in the compartment proposal)
17:00	<guybedford>	Yeah ModuleInstance is just a suggested approach to move beyond needing a full fledged loader, but definitely moving towards a unified module record would be a huge step forward.
17:00	<guybedford>	Asset reflection as a preload primitive is a really interesting area as well
17:01	<guybedford>	eg `import.preload(asset)` or similar
17:01	<littledan>	it's pretty difficult to separate these things; I don't think they need to advance stages together, but we'll need a unified design in mind
17:01	<Kris Kowal>	ModuleInstance exists but is hidden in the Compartment proposal. We can riff on details if we want to make that public.
17:02	<Kris Kowal>	e.g., it can be generalized to language-agnostic. new ModuleInstance(bindingsArray) => { ModuleExportsNamespace, ModuleEnvironmentRecord }
17:03	<littledan>	I think we'll need a separation between the concrete class and the underlying protocol (to allow WebAssembly.Module to conform to the same protocol)
17:03	<Kris Kowal>	StaticModuleRecord(source) => { bindings, initialize( ModuleEnvironmentRecord, { Import, ImportMeta }) }
17:03	<littledan>	the rest of the things will be instances of the shared class
17:03	<littledan>	(internal [[internalSlot]] protocol of course)
17:04	<Kris Kowal>	Yeah, WebAssembly.Module overlaps the current Compartment draft’s notion of a third-party/synthetic static module record, though the API differs, a small adapter suffices.
17:04	<littledan>	what do you think of, rather than requiring an adapter, making it "just work"?
17:05	<Kris Kowal>	It could be done. It’s only a little non-idiomatic. WASM modules have a strange notion of dynamic dispatch.
17:05	<littledan>	sorry we should split this conversation out into the subgroup, maybe we should make a separate matrix room?
17:05	<Jack Works>	what do you think of, rather than requiring an adapter, making it "just work"? host implement module record internal slots for WebAssembly.Module
17:05	<littledan>	It could be done. It’s only a little non-idiomatic. WASM modules have a strange notion of dynamic dispatch. oh OK I'll have to reread your compartments PR to understand this mismatch
17:05	<Kris Kowal>	Aye, please be welcome in #tc39-compartments:matrix.org
17:14	<Luca Casonato>	was a link to these slides shared at some point? sorry, they were very in flux. link here: https://docs.google.com/presentation/d/1y0MAo7ymIWzyyrU9o3oKLiHc4BtQwLtqlU4Z_8_XYjU/edit?usp=sharing
17:15	<ryzokuken>	sorry, they were very in flux. link here: https://docs.google.com/presentation/d/1y0MAo7ymIWzyyrU9o3oKLiHc4BtQwLtqlU4Z_8_XYjU/edit?usp=sharing no worries, thanks for sharing!
17:21	<Luca Casonato>	so i took that to mean the API parts are exploratory, needed to be unified with other proposals, etc yes, that is our intention.
17:53	<shu>	cross-posting here for visibility: plese fill out the doodle for the module harmony call if you're interested: https://github.com/tc39/Reflector/issues/436