| 19:45 | <Kris Kowal> | nicolo-ribaudo: Caridy is working on First-class Modules spec text. It might be good for you to connect. |
| 19:46 | <Kris Kowal> | One thing we can’t do Right Now™ is have importHook and importMeta fall through to defaults in the realm. I presume this is because we don’t have [[ImportHook]] or [[ImportMeta]] on the realm record Yet™. |
| 19:47 | <Kris Kowal> | And if we had them, they’d have to be host-defined. |
| 19:47 | <Kris Kowal> | Maybe we have them but they have other names or forms that obscure them? |
| 19:51 | <guybedford> | Kris Kowal: great to hear progress is coming along! Happy to assist where I can as well. I wonder if the importHook could be treated as an internal operation to start to avoid the realm issues? As in, a spec function doesn't need to have context? Eg paramaterize HostResolveImportedModule by the realm (as it likely should be), and have import hook delegate to that? Then refactor outwards from there? Thinking aloud... not sure if something like that makes sense. |
| 19:52 | <Kris Kowal> | I think that makes sense. |
| 19:52 | <Kris Kowal> | Something very much like that in any case. |
| 19:53 | <guybedford> | Do you plan to put time to these discussions in SES meetings? Or can we resume in our modules meetings? |
| 19:53 | <guybedford> | I can also reach out to caridy as well / or just copy in on anything for feedback too |
| 19:54 | <Kris Kowal> | I would like to get crackin’ on nitty gritty as soon as possible and SES meetings will help with that. The contract with Module Harmony calls remains the same, though. When we get together with the stakeholders, have to present from where the group left off. |
| 19:55 | <Kris Kowal> | But just putting heads together with Caridy, Nicolo, you, and me to puzzle out what’s possible also makes sense to me. |
| 19:55 | <guybedford> | yeah I'd be happy to put some time into the direct spec questions |
| 19:56 | <guybedford> | I'm still very hopeful we can improve the modules spec as we do this work |
| 19:56 | <guybedford> | and actually make it more capable and more well-defined in the process |
| 19:57 | <Kris Kowal> | Yeah, on the one hand Caridy wants to have the lightest touch possible so the proposal is provably free of surprises. |
| 19:57 | <Kris Kowal> | But I think setting up for a non-normative refactor should be part of the plan. |
| 19:57 | <guybedford> | If there's room for some refactoring, like working on any old codebase hopefully we can leave it better than we found it :) |
| 19:58 | <Kris Kowal> | Or preceding with a non-normative refactor would work for me too. |
| 19:59 | <Kris Kowal> | Are you familiar with Chesterton’s Fence? |
| 20:04 | <Richard Gibson> | I always dismiss Chesterton's fence discussions because I don't see their purpose |
| 20:07 | <Kris Kowal> | Yeah, so relatedly, I suspect that Cyclic Module Record only exists because Module Source Record doesn’t exist yet. |
| 20:08 | <Kris Kowal> | But I don’t know know whether there are any concrete Module Record types that don’t include the abstract Cyclic Module Record. |
| 20:08 | <Kris Kowal> | So I’m approaching that particular Chesterton’s Fence as if it might be electrified. |
| 20:09 | <Kris Kowal> | That kind of uncertainty is a good reason to refactor it out of existence, if we can. |
| 20:13 | <Kris Kowal> | So I think the way we set the stage for that refactor is to create a new concrete Module Record that embeds Cyclic Module Record and refers to a Module Source Record. This would be the last concrete Module Record we would ever need, and in a refactor, we could circle back and replace the Module Record abstract type hierarchy with the single, concrete Module Record and rely on the abstract Module Source Record for extensibility. |
| 20:13 | <Kris Kowal> | In that refactor, Cyclic Module Record squashes into Module Record. |
| 20:14 | <Kris Kowal> | But, again, weary that might not be possible and is also not necessary to make progress on “Virtual Module Record”. |
| 20:14 | <Kris Kowal> | And very very weary of signaling that the refactor is necessary, given that it might not be possible. |
| 20:24 | <Kris Kowal> | guybedford (Guy Bedford): And I’m sure that’s the least of the refactoring you have in mind. 😂 |
| 20:45 | <guybedford> | interesting! |
| 20:46 | <guybedford> | I wonder if we could do such a refactoring as a non-normative PR? |
| 20:46 | <guybedford> | perhaps write our respective specs, then work out a refactoring to write our respective specs against, then PR that first...? |
| 20:48 | <Kris Kowal> | I think any refactoring is by definition non-normative. |
| 20:49 | <guybedford> | yeah I guess its more likely, let's get this spec feedback going on see where it ends up though |
| 20:50 | <guybedford> | I also think we could generalize CyclicModuleRecord istead of AbstractModuleRecord being separated |
| 20:50 | <guybedford> | Then having ModuleSourceRecord v ModuleInstanceRecord |
| 20:51 | <guybedford> | In theory SyntheticModules could just be a CyclicModuleRecord with no dependencies |
| 20:51 | <guybedford> | and that leaves the door open to a form of Synthetic with dependencies anyway |
| 20:51 | <Kris Kowal> | A thing I could use help explaining is why we should separate source from instance. |
| 20:52 | <guybedford> | I guess the new constraint is the same source record can now have multiple instances under module blocks |
| 20:52 | <Kris Kowal> | that’s certainly true |
| 20:52 | <Kris Kowal> | multiple instantiation is the crux, and multiple motivating cases require multiple instantiation |
| 20:53 | <Kris Kowal> | there’s also transferability between agents of the same cluster. I think James Browning (@?) would be very interested in that dimension. |
| 20:54 | <Kris Kowal> | toll-free transfer between realms too |
| 20:55 | <Kris Kowal> | i suppose it’s incidental is that it fixes the encapsulation boundary |
| 20:55 | <Kris Kowal> | “encapsulate the thing that varies” |
| 20:55 | <guybedford> | yeah these seem to be the main points I think? - cyclic / abstract unification, instance / source separation, multi agent / realm usage |
| 20:55 | <Kris Kowal> | source types vary, module lifecycle management does not |
| 20:56 | <guybedford> | then cache semantics and host hook modifications I guess |
| 20:58 | <littledan> | yeah I agree that you can just use CyclicModuleRecord for more things |
| 20:58 | <littledan> | it doesn't hurt to have that logic around |
| 20:58 | <littledan> | (or maybe that's not what you're saying?) |
| 20:58 | <Kris Kowal> | It’s one of the things I’m saying. |
| 21:01 | <Kris Kowal> | Separating module source from instance moves the abstraction boundary to a better place than where it is at the moment |
| 21:02 | <Kris Kowal> | Some of the concerns of Source Text Module Record belong on the Source side and others on the Instance side. |
| 21:02 | <Kris Kowal> | But all of the concerns of Cyclic Module Record belong on the Instance side. |
| 21:03 | <Kris Kowal> | When the Instance side has all the right concerns, it becomes clear that you only need one concrete Instance type and many derived Source types. |
| 21:04 | <Kris Kowal> | But, again, a refactor is not necessary to make progress. |
| 21:06 | <Kris Kowal> | I’m proposing that we just make a new Virtual Module Record type that embeds Cyclic Module Record and borrows some properties of Source Text Module Record (everything but the Source!), then makes a reference to a Module Source Record that keeps the remaining bits of Source Text Module Record. |
| 21:07 | <Kris Kowal> | We’d leave the existing Module Record hierarchy in tact, maybe circle back clean it up later. |
| 21:09 | <guybedford> | I guess one of the difficulties is that because SourceTextModule extends CyclicModule extends AbstractModule, having parts of SourceTextModule refactored into a ModuleSource, doesn't mean all abstract modules have a ModuleSource? |
| 21:10 | <Kris Kowal> | Correct. |
| 21:10 | <Kris Kowal> | And when you put it that way, maybe a refactor is necessary. |
| 21:11 | <Kris Kowal> | Or Module instances could end up with a null source, and that’s not good for business. |
| 21:12 | <guybedford> | Right, so how to define source in cases where it's under-specified? |
| 21:12 | <guybedford> | short of just having a bunch of null entries on a record |
| 21:13 | <Kris Kowal> | Refactor is getting compelling. |
| 21:13 | <guybedford> | I think realistically we only have to handle SyntheticModule and CyclicModule |
| 21:13 | <guybedford> | but even JSON as a SyntheticModule could in theory associate with its source |
| 21:13 | <Kris Kowal> | Yes. |
| 21:14 | <guybedford> | I'd be very keen to be involved in a refactoring effort, and will gladly sling some PRs on a shared repo |
| 21:15 | <Kris Kowal> | Dan made a point to me on the way out of plenary yesterday, that module fragments might not be able to have a source. So nullable source might be on the table, but I would like to avoid that. |
| 21:15 | <guybedford> | if it's better to do under the compartments umbrella for now happy to do that as well |
| 21:15 | <guybedford> | if you have a link to what Caridy is working on please do share |
| 21:15 | <guybedford> | yes Dan explicitly mentioned for import reflection he wants to see the fragments etc use cases worked out at a spec level |
| 21:15 | <guybedford> | we can certainly do that |
| 21:16 | <Kris Kowal> | I’ll pass Caridy’s work along when I get it. |
| 21:17 | <Kris Kowal> | TBD on making a new proposal repo for each layer of a “modules epic”. Going to put that on agendas. |