Fix notes for my modules harmony slides

meetings/2023-05/may-15.md

@@ -460,21 +460,27 @@ Presenter: Nicolò Ribaudo (NRO)
 
 - [presentation](https://docs.google.com/presentation/d/1mZrAHHimtM_z_8fM9L3DUXFz5bjlJPxx8VrwsC68hmk)
 
-NRO: So, hello everyone. This presentation, is a specific proposal and how the Module Harmony and semantics interaction. And so with this discussion, we will provide scope of discussion. And like every topic which effects proposal and every topic that does have a clear effect of proposal but still has the scope.
+NRO: So, hello everyone. This presentation, is not about a specific proposal, but about what Module Harmony is and semantics interaction. This slide shows scope of this discussion: every topic which effects proposal and every topic that does have an effect on multuple proposals is still in the scope. Okay, so, I suggest this scope of discussion if you have like an in-depth discussion regarding some aspect of proposal, please consider discussing that in discussions specific to that proposal.
 
-NRO: Okay, so, I suggest this scope of discussion if you have like n in-depth discussion regarding some aspect of proposal, and so you have the statement of the proposal, and please consider discussing of that in addition to the proposal at this general discussion. So, what the proposal is covered by these slides? All of them. All of the proposals that we are working with and so import attributes. And module expressions and module declaration and local imports and the module source and imports. And then, all the proposals that follow understand the compartments.
+NRO: So, what the proposals are covered by these slides? All of them. All of the proposals that we are working on: import attributes, module expressions, module declaration and local imports, the module source imports. And then, all the proposals that under the umbrella of compartments.
 
 NRO: And we have presented multiple times about how all of the proposals depend on each other but in the past few months we have further refined the dependency graph. And with the proposal dependencies but we try to have the color lines of value of proposal and there are dependencies between the concepts and many proposal do not have dependencies, and the yellow and blue lines have dependency and the two.
 
-NRO: So, okay, so now let’s introduce this topic: how do the various proposals interact. And the forward for each interaction we care about and the first give a quick summary of what the proposals are and to show after how they interact. And for the first interaction, that is internalized is how to module source imports interact with the import evaluation, and so when looking at all of the important phases and I will go quick. And so module source imports. And module instance imports is a way to import a module without loading its dependencies and so like this will have the less representation of the model, and an example of this is object. And so this [INDISCERNIBLE]. And so the it is impossible to load all of them the dependencies and so you go about these concept attached to the model. These two modules is a part of enter reflection. And so the important part of about proposal and linking the module and execution is when the model experts are used. And as presenting at this time the interaction between these two would be explanation of how these things fit together. And that is model process can be done in these five steps. And so model and context, and then you link them related. And the imported reflection are like two phases of this assessment while the import phase and these are modeling and then we have interacting between model expressions and module loader hooks. And so our module expression is allowing declaring modules inline inside other modules and this model will give us something that can be later imported. And loader hook module and applying some custom behavior, and so currently, the loader hook the intersect the imports, and otherwise define how the modules are linked and we have module expression which is same thing module expression, and all of these will result in the same object. So all of these proposals we are developing separately, they come appoint of this module class. You can see on the slide. Because all of these proposals will give us a module that will give us context attached. And this means that the custom linking in the module loader hook proposal is a hook that should return some instance of the module class can be used with these other proposal, and so you can return module using import module reflection or you can use module expression or with other custom hooks’ behavior. And this is important because it allows partial virtualization of the module class, and if you only have module hook proposal, the hook will have to return with the module class, and so this is declaring some like module loader behavior and we don’t need to virtualize every single module on the graph, at any time we can return the module expression or with the – these are delegating back to the host.
+NRO: So, okay, so now let’s introduce this topic: how do the various proposals interact. And the forward for each interaction we care about and the first give a quick summary of what the proposals are and to show after how they interact. And for the first interaction, that is how module source imports interact with defer import evaluation, and we alreadt looked at the concept of phases at the previous meeting so I will go quick. And so module source imports (and module instance imports) is a way to import a module without loading its dependencies, and so it will give a different representation of the module, an object. And so the it is then possible to load all of the dependencies and so you go about these concept attached to the modules. These two modules is a part of enter reflection. And so the important part of defer imports is that it links the module, but execution happens when the module exports are read. And as presenting at this time the interaction between these two would be explanation of how these things fit together. And that is module loading process can be done in these five steps. And so fetch/compile the module and attach its context, and then you link them later. And the imported reflection are like two phases of this process.
 
-NRO: And similarly, we can use source phasing import in particular module source without context and – this is not entirely sympathized by user code. We can refer to the host for these module, and so you have like the common policy and behavior and you can attach some custom like hooks behavior to this module. Then, we have the interaction between module declarations and the module instance phase import. And module declaration is declaring models of some lines of expression and they can be statically imported from. Things that we can see binding is a module declaration, and you can have import and import from other module and import from the module declaration and this all statically analyzable. And module instance alone creating like the module extent but they do have some very particular syntax because that is part of module declaration. And so this we can reuse the same import from a module in syntax, and in this example here we have some module instance import and the import module and later import client from this module. So this will continue the process that does not finish continuing the process because we only interacted with the module. And so in this case in this particular environment, and use this for management and some package manager. So there are some – so work around centralizing all the imports. And exporting everything that might be necessary; and this has problems because you are suddenly sharing a single namespace between all the library and you need to bring into the exports and all the dependencies are related and so when using [INDISCERNIBLE]. These combination of these proposal and in which dependency you need, you don’t have all the dependencies and relating them until then you have centralized in a single place.
+NRO: Then we have interacting between module expressions and module loader hooks. And so what module expression is allowing declaring modules inline inside other modules, and this module will give us something that can be later imported. And loader hook module and applying some custom loading behavior, and so currently the loader hook intercepts the imports, and otherwise define how the modules are linked. And we have module declarations which is same thing module expression, and all of these will result in the same object. So all of these proposals we are developing separately, they share this common module class. You can see on the slide. Because all of these proposals will give us a module that will give us context attached. And this means that the custom linking in the module loader hook proposal is a hook that should return some instance of the module class can be used with these other proposal, and so you can return module using import module reflection or you can use module expression or with other custom hooks behavior. And this is important because it allows partial virtualization of the module graph, and if you only have module hook proposal, the hook will have to return with the module class, and so this is declaring some like module loader behavior and we don’t need to virtualize every single module on the graph, at any time we can return the module expression whose imports are delegated back to the host.
 
-NRO: The next interaction that is important for our proposal is how module declarations and expressions interact with the import attributes proposal. And this model can be later imported. Import attributes is parameters to hosts loader and how they are related and so the host will check, well, specifically the HTML will change the header to server to communicate which contact is accepted and we then check the content provided matches the expected content. When, we consider these two proposals together, we see module declaration, and so you cannot pass import attributes to the module expressions and for example, here, one is adjusted model and you cannot modify this. You might wants to extract the source of module object you have in the module equation and not execute until it is needed. So this is another example of why we decided to split the import parts of this proposal from the various phase modifier.
+NRO: And similarly, we can use source phasing import (in particular, module source imports without context) to load a module at the host level. We can refer to the host for these module, and so you have like the CSP behavior and you can attach some custom hooks behavior to this module.
 
-NRO: So we have interaction between module loader hooks and import attributes. And module loader hooks give a way to intercept all imports of a module, and resolve them with custom logic and so then attributes can affect how the module is loaded and evaluated and the import attributes is from the host. So if you have import with two different attributes, does not matter which order you define them, and the result must be the same. So the way you can integrate attributes and module loader hooks is to have a supported attribute array and that is equivalent to the hosts’ hooks and the heat define which to import. And so the hook cannot change its behavior based on the import attributes, and the import hook is called once the specifier has attributes pair because it is hook will define the host. So if you have for example, a module with this four imports, and another hook that does not support the type attribute, the import hook will call three times, and once for the second import which is attribute and one for the third import because it is specifier for the hook. And if we try to use this custom hook with some attributes that is not supported, we will get an error. Again to – how the module hooks interact with the import phase modifiers. And so this the modify of how not effect what the host asks the host cannot change how it is modified. And when we try to integrate these two proposals, the import hook doesn’t receive the import phase. And the import hook is called once per specifier and makes sure that all the phases import for the file represent match what the host has.
+NRO: Then, we have the interaction between module declarations and the module instance phase import. And module declaration is declaring modules similar to module expression, but they can be statically imported from. Things that we can see "this binding is a module declaration", and you can have import them from other modules and import form the module declaration, and this all statically analyzable. And module instance allows creating the module extent but they do have some very particular syntax because that is part of module declaration. And so this we can reuse the same import from a module in syntax, and in this example here we have some module instance import and the import module and later import client from this module. So this will continue the import process that did not finish, continuing the process because we only interacted with the module. And so in this case in this particular environment (such as Deno), we use this for dependencies management without a package manager. So there is some work around centralizing all the imports. And exporting everything that might be necessary; and this has problems because you are suddenly sharing a single namespace between all the library and you need to bring into the exports and all the dependencies are loaded also when actually using just a few of them. These combination of these proposal and in which dependency you need, you don’t have all the dependencies and loading them even if you have centralized in a single place.
 
-NRO : So, we have a source phase import and the hook will return and if we have module import hook, that will return a module, and if we have a deferred import the module hook will log dependency and then we will not emulate the module. And this will be called interaction points. And I am happy to go in details with you. There are many proposals to work out, and trying to advance it. However, we have to consider how all of them interact. So we have to define some goals regarding how to handle dependencies and interaction points between different proposals. And our principles is that every proposal must be able to move ahead independently from the other proposals unless there is obvious dependency, and all proposals must be self-motivated and because some of these interaction is not fix and multiple proposals together can solve the problem or cases and all of this proposal must have, if any proposal gets stuck or does not receive consensus, the other parts can stand without it – so that when ever you have a language in a state where something is a little bit off waiting for proposal, it still makes sense. And lastly, we are trying to minimize dependencies on each other, to allow the proposals to advance..
+NRO: The next interaction that is important for our proposal is how module declarations and expressions interact with the import attributes proposal. And this module can be later imported. Import attributes is parameters to hosts loader and how they are related and so the host, specifically HTML, will change the header to server to communicate which contact is accepted and we then check the content provided matches the expected content. When, we consider these two proposals together, we see module declaration, and so you cannot pass import attributes to the module expressions and for example, here, one is adjusted module and you cannot modify this. You might wants to extract the source of module object you have in the module equation and not execute until it is needed. So this is another example of why we decided to split the import parts of this proposal from the various phase modifier.
+
+NRO: Then we have interaction between module loader hooks and import attributes. And module loader hooks give a way to intercept all imports of a module, and resolve them with custom logic and so then attributes can affect how the module is loaded and evaluated and the import attributes is from the host. So if you have import with two different attributes, does not matter which order you define them, and the result must be the same. So the way you can integrate attributes and module loader hooks is to have a `supportedAttributes` array and that is equivalent to the hosts hook to define which attributes it provided. And the hook cannot change its behavior based on the import attributes, and the import hook is called once the specifier has attributes pair because it is hook will define the host. So if you have for example, a module with this four imports, and another hook that does not support the type attribute, the import hook will call three times, and once for the second import which is attribute and one for the third import because it is specifier for the hook. And if we try to use this custom hook with some attributes that is not supported, we will get an error.
+
+NRO: Then, how the module hooks interact with the import phase modifiers. And so this the modify of how not effect what the host asks the host cannot change how it is modified. And when we try to integrate these two proposals, the import hook doesn’t receive the import phase. And the import hook is called once per specifier and makes sure that all the phases import for the file represent match what the host has. So, we have a source phase import and the hook will return and if we have module import hook, that will return a module, and if we have a deferred import the module hook will log dependency and then we will not evaluate the module.
+
+NRO: And this was all for the main interaction points. I am happy to go in details with you. There are many proposals to work out, and trying to advance them. However, we have to consider how all of them interact. So we have to define some goals regarding how to handle dependencies and interaction points between different proposals. And our principles is that every proposal must be able to move ahead independently from the other proposals unless there is obvious dependency, and all proposals must be self-motivated and because some of these interaction is not fix and multiple proposals together can solve the problem or cases and all of this proposal must have, if any proposal gets stuck or does not receive consensus, the other parts can stand without it – so that when we never have a language in a state where something is a little bit off waiting for proposal, it still makes sense. And lastly, we are trying to minimize dependencies on each other, to allow the proposals to advance.
 
 NRO: And so this is again the graph of all the modules that depend on each other, and there are many parts. So we have working part which is source and this is in module loader hooks, and then we will introduce the module source and it is language. And that will happen with the module object and instance which is made by different virtual, and module hook, and the module instance phase. Then there are proposals that while there are interactions that we need to take care of and have not really shared that concept totally dependency with other proposal. This is all. One of the goals with this presentation was to clarify how it all interacts and because in past meetings it was questioned how all of this fits together. So I hope I clarified some of those and I will go to the queue to discuss any further concepts or questions if there are any.