15:05
<Kris Kowal>
yulia: Welcome back. Hope you’re feeling better.
15:05
<yulia>
thank you!
15:05
<yulia>
i am still catching up on things
15:05
<yulia>
i did see the mention regarding whether or not the lazy loader case is subsumed by exposing the loader internals. it is something i've thought of a lot myself
15:06
<yulia>
I had some feedback from developers recently, who are concerned that things are about to get a lot more complicated, and also that lazy doesn't mean much to them. It is more of a hint for engines. People however resonated with something like pure or library. These terms may be more meaningful from a developer perspective than exposing low level blocks (which are independently useful), or something to oriented towards engines like lazyInit. This achieves the same goal as lazyInit, but is meaningful for both engines and developers on the same rubric. No global state modification, safe to defer, etc.
15:07
<yulia>
so, I think there is still a reason to explore a higher level, opinionated api -- it may communicate programmer intention better
15:07
<yulia>
i need to catch up on the discussions that happened here more first, before anything
18:47
<Kris Kowal>
Having both high and low level APIs sounds reasonable to me. That reasoning might apply to compartments, though the low-level design would certainly inform the high-level design. I sketched high-level Compartment in terms of low-level Module and ModuleSource. https://gist.github.com/kriskowal/f48fb0c68a70ccbde7cd32c85cddc63c
18:51
<Kris Kowal>
I think low-level import reflection or deferred import do obviate one complication of the Compartment design (as written right now), regarding how to communicate a module source or module instance from a host compartment to a child compartment. That isn’t possible to express in terms of the low-level parts, which compels the developer to use import reflection or deferred import explicitly. That might be a good outcome, even for XS. Currently XS depends on a manifest to express the full working set, but these features together would allow tooling to take over more of the tedium.
18:55
<Kris Kowal>
In any case, for plenary, I hope to have a deck ready tomorrow that shares an update on the evolution of the compartments proposal over the last couple of years that decomposes it into smaller proposals, starting with low-level first-class Module and ModuleSource and ending in Compartment.
18:55
<Kris Kowal>
There appear to be four separable layers.
21:14
<shu>
btw could we get a volunteer to run the next call?
21:37
<littledan>
by "run the next call" do you mean what I did in the last call or something else?
21:37
<littledan>
I'm fine repeating what I did
21:46
<shu>
i mean what you did last call, yes
21:46
<shu>
excellent