TC39 Module Harmony on 2022-12-20

16:57	<nicolo-ribaudo>	I'll join the meeting ~10 minutes late
18:40	<Luca Casonato>	The latest iteration of the syntax proposal as discussed: https://gist.github.com/lucacasonato/6f7db6a449fd7e047999343810309ca0 Only "as" is part of the cache key and it is interpreted exclusively by the host hook. It can be any primitive (including records & tuples when they ship). All other keys in the import options are not cache keys, and are defined and interpreted exclusively by ECMA262. They are never passed to host hooks or the compartments import hook.
19:01	<Kris Kowal>	Justin Ridgewell, for the record, please confirm your position is that a mechanism that feeds into the cache key is necessary, and an `as <primitive>` + records and tuples as primitives would suffice.
19:01	<Kris Kowal>	Let’s get this written up in our minutes. Thank you Luca Casonato
19:14	<littledan>	huh, what's the rationale for the # being in the syntax?
19:15	<littledan>	not all primitives can be included (e.g., symbols can't) so conceiving of this as "primitives" seems a little funny
19:16	<Kris Kowal>	The reified value corresponding to the syntax must be a primitive.
19:16	<littledan>	ah, OK, why?
19:16	<Kris Kowal>	In order to ensure that the cache key is canonical.
19:17	<littledan>	ah
19:17	<Kris Kowal>	Also, given that this is occurring pre-evaluating, that imposes some limits on what’s expressible.
19:17	<littledan>	well.... we should keep in mind the possibility that R&T won't go to Stage 3 in their current form
19:17	<littledan>	I don't even know if we have consensus on having any kind of syntax for them, at this point.
19:18	<Kris Kowal>	That is to say, however the value is lifted off the page, it has to occur in the parse phase, not the evaluation phase, and not in a lexical scope, so what’s expressible is inherently limited. I don’t have strong feelings about how that’s expressed syntactically.
19:18	<Kris Kowal>	Yeah, we’re aware that this is precarious.
19:19	<littledan>	(R&T syntax obviously doesn't imply that it doesn't contain expressions)
19:20	<Kris Kowal>	As solutions go, this so far uniquely addresses all the concerns of both cache key formation, separation of the cache key namespace from non-cache key namespace, and extensibility in bundlers such that the portions participating in the cache key are visible to importHook.
19:20	<littledan>	also why not : after as? does that indicate that it's part of the cache key?
19:20	<Kris Kowal>	Yes, `as` indicates both that it participates in the cache key, allows for composite cache keys, and threading to import hook.
19:20	<littledan>	well, I'm not sure if using the : for the other keys does a great job indicating that visually
19:21	<littledan>	as opposed to just, remembering the name
19:21	<Kris Kowal>	Using the colon is not germane, I think.
19:21	<littledan>	anyway: I'm happy with the general design of having `as` participate in the cache key, and the other keys are defined by ecma262 and do not
19:22	<Kris Kowal>	That is to say, we’re looking for any syntactic solution with the properties: distinguishes cache key from not if cache key, also visible to import hook cache key is extensible cache key canonicalizes order
19:22	<littledan>	Should we still design things (e.g., import()'s second arg, the thing passed to importHook) to allow more keys in the cache besides `as`, even if we don't define them yet?
19:23	<Kris Kowal>	We also have general support among participants that dynamic `import(x, bag)` corresponds 1:1 to a shallow static import syntax managed by 262.
19:23	<Kris Kowal>	Yes. That’s the direction supported by everyone on the call.
19:23	<littledan>	We also have general support among participants that dynamic `import(x, bag)` corresponds 1:1 to a shallow static import syntax managed by 262. I see, that sounds ideal
19:24	<littledan>	yeah this sounds like a huge amount of progress that you all made
19:24	<littledan>	who were the attendees participating in the agreement?
19:25	<Kris Kowal>	That is to say, what gets plucked from the options bag is determined by 262, and anything else would presumably get ignored. What gets threaded to importHook is just specifier and `as`. Every other key has behavior well-defined in 262.
19:26	<littledan>	hmm, ignored, and not treated as an error?
19:26	<Kris Kowal>	Present and participating on todays call were Justin Ridgewell nicolo-ribaudo yulia guybedford Luca Casonato and myself. Mathieu Hofman and Richard Gibson observed. Please forgive any omissions!
19:26	<littledan>	(I've heard arguments on both sides and was personally leaning towards "error")
19:26	<Kris Kowal>	hmm, ignored, and not treated as an error? I say presumably because that detail was not discussed, but forward compatibility is desirable.
19:26	<Kris Kowal>	Yeah, I could be swayed either way.
19:26	<littledan>	forward compatibility cuts both ways
19:27	<littledan>	or, I guess leans towards error
19:27	<littledan>	the counterargument is "upgrade path" which is a bit different
19:27	<Kris Kowal>	Again, I’ve not thought in depth on that detail. I’m presuming from the hip.
19:29	<littledan>	well, anyway, I'm extremely happy with this direction, and looking forward to the details being spelled out. Did someone sign up for that part?
19:30	<Kris Kowal>	In any case, it was a good conversation and we found that there’s not a great deal of disagreement in abstract and we just need to get more concrete about one of the many possible directions. Possibly a statement of some kind about vision for evolution of this keyspace and how we accommodate it. guybedford expressly doesn’t want to push in that direction and recognizes that import reflection needs a color for that bikeshed, just doesn’t have strong color preferences. Just a preference not to be blocked on the issue for long.
19:31	<Kris Kowal>	I’m personally hoping you’re up for writing something up, littledan.
19:31	littledan	hides
19:31	<littledan>	can I nominate... anyone but me to do this?
19:31	<littledan>	all of you who were in the discussion would be good
20:16	<Justin Ridgewell>	Justin Ridgewell, for the record, please confirm your position is that a mechanism that feeds into the cache key is necessary, and an `as <primitive>` + records and tuples as primitives would suffice. Yes, having some extensible mechanism that feeds into the cache key is a necessity for things we want to implement in our bundler. If we want to specify that as allowing records, that fine, though I don't see much difference between a record cache key and cache that does a shallow (non-ordered) equality of a static object literal.
20:21	<littledan>	well, one difference is Records don't exist yet...
20:22	<Justin Ridgewell>	As for why an extensible value that participates in a cache key is necessary, we can draw from the `@next/font` examples. Currently, you have a runtime function that has to be invoked with options, but if that function escapes the callgraph at all, it's not possible to analyze anymore. I'd be ideal if we can move all these settings into the `as` record, so that we have a guaranteed static analyzable syntax (this is standard static syntax improves ergonomics vs dynamic evaluation). I've actually reliazed last week that this is all dev facing, I failed to consider that when I was describing this previously.
20:24	<littledan>	so the syntax will help explain the limitations on usage, making it non-escaping by construction?
20:24	<littledan>	I kinda thought that having it refuse to build with a descriptive error message would be enough
20:26	<Justin Ridgewell>	Yes, we can fail the build if we see things that aren't correct, but still not a great DX
20:27	<Justin Ridgewell>	It'd be better if we can syntactially say that something doesn't work
20:27	<Justin Ridgewell>	Eg, what if the user does `Roboto({ weights })`, with `weights` being some dynamic array?
20:28	<Justin Ridgewell>	A static import syntax improves DX by having obvious restrictions
20:48	<Kris Kowal>	As for why an extensible value that participates in a cache key is necessary, we can draw from the `@next/font` examples. Currently, you have a runtime function that has to be invoked with options, but if that function escapes the callgraph at all, it's not possible to analyze anymore. I'd be ideal if we can move all these settings into the `as` record, so that we have a guaranteed static analyzable syntax (this is standard static syntax improves ergonomics vs dynamic evaluation). I've actually reliazed last week that this is all dev facing, I failed to consider that when I was describing this previously. The case of fonts is interesting because it involves a need to merge the expression of dependencies at a particular commit point that doesn’t exist in the Module API but necessarily exists with bundlers.
20:48	<Kris Kowal>	A commit point beyond which no further modules will be imported, that is.
20:50	<Justin Ridgewell>	I think that's an optimization, but not a requirement. When I was doing font work for AMP, I saw tons of publishers who would have multiple imports for the same font with different variations, or multiple imports for different fonts with the same variations. They could all be coalesced into a single stylesheet request, but it's prevented
20:59	<Kris Kowal>	That optimization might be expressible in terms of the proposed framework.
21:22	<shu>	Kris Kowal: you've had access to the transcript docs, right?
21:27	<littledan>	A static import syntax improves DX by having obvious restrictions OK, I can understand this; thanks for explaining.
21:40	<Kris Kowal>	Kris Kowal: you've had access to the transcript docs, right? I got a transcript for this week and will post shortly.
21:40	<Kris Kowal>	Mathieu Hofman had the foresight to get a transcript last ~~week~~ fortnight.
21:42	<shu>	Kris Kowal: cool just wanted to make sure they were accessible
21:43	<Kris Kowal>	Ah, I see. They show in your drive, but since I pressed the button, I’ve also got access. Thanks.
21:43	<Kris Kowal>	I’ll “yeat” that up now.
21:49	<Kris Kowal>	I’ve posted a summary of our conversation and the transcription. https://docs.google.com/document/d/1CD5lIBZLl24XBWbQhokqBdt4Zl7wPAcFJKJrgePr9HU/edit#bookmark=id.wpzrt0f9aa58
22:31	<shu>	that reminds me
22:31	<shu>	do you think the new yorker writes yeët
22:32	<Kris Kowal>	Not unless it’s polysyllabic. The diaeresis indicates that eë is not a diphthong.
22:33	<Kris Kowal>	Which is to say, stress between the first and second E.
22:33	<shu>	do you not say yee-it
22:33	<Kris Kowal>	I don’t but I’m not a member of the correct generation to speak authoritatively!
22:34	<Kris Kowal>	Pretty sure “yeet” lasted approximately negative ten minutes in the collective consciousness of neologisms.
22:34	<shu>	on god i'm old too
22:35	<Kris Kowal>	I’m told the appropriate reactji is ☠️ but I’m going to run with X-\| in solidarity.
22:39	<Kris Kowal>	But the fun game is using a diaeresis in words that the New Yorker probably never had reason to print. Like, “reïfy”.
22:40	<shu>	sick