✏️ fix whitespace problems

meetings/2023-05/may-15.md

@@ -582,11 +582,11 @@ LCA: What we are proposing is to add a way to import specifically this source ph
 
 LCA: So syntax. In previous presentations, we had considered whether the loading phase can be part of import attributes. Especially attributes can now affect loading and we have concluded this is not suitable and putting the phase in the attribute is not suitable. And one reason is that loading phase can some asset reference and this can only have default binding and deferred-eval imports only support `* as ns` binding and so imports at Istanbul modify module loading but think don’t they have early exit. So yeah, so these are fully composable – you can have a module – you can import something as earlier phase as like the source phase, and so the specific phase syntax is `import <phase> <binding> from <specifier>` and then import attributes (“with” attributes) at the end. And the phase is in front of the bindings because the phase enforce what syntax bindings are and avoids color grammar and there is a dynamic form of this is which is the import – dynamic import as usual with the phase specified as a stream in the option bag. This phase syntax, there is little note at the bottom of the slide which says phase syntax by convention, not specification, so we are trying to come up with a unified syntax that can be shared across all proposals and we don’t have a bunch of different behaviors that don’t interact with each other.
 
-GB: Okay, so, to pick up again and again this is a recap mostly from the last presentation. What we are proposing initially from the import sources is to support web assembly source import, and what is quite nice about this implementation path is that it allows us to solve for the web assembly use case without having to fully workout at this point what we are reflecting for JavaScript modules. So it allows us to cover a simple version of the source imports that we can potentially extend to JavaScript in the future, and now we have web assembly – next slide. Is basically it what follows a bunch of interesting assembly in the web case, and like in the previous slide we can avoid that complex syntax that you need that is commonly understand and it is difficult for the preloader in the browser to understand what is being loaded. And by  utilizing the static syntax in the module system, we can share the same security policy and host resolution policy, and get all the benefits of that and we get unified syntax that can use both in browser and server-side runtimes so it provides some API and when you run web assembly this is most common path because fact that there is most often very specific imports that need to be provided for the modules to make them execute. So it is needed above and beyond the interesting integration.
+GB: Okay, so, to pick up again and again this is a recap mostly from the last presentation. What we are proposing initially from the import sources is to support web assembly source import, and what is quite nice about this implementation path is that it allows us to solve for the web assembly use case without having to fully workout at this point what we are reflecting for JavaScript modules. So it allows us to cover a simple version of the source imports that we can potentially extend to JavaScript in the future, and now we have web assembly – next slide. Is basically it what follows a bunch of interesting assembly in the web case, and like in the previous slide we can avoid that complex syntax that you need that is commonly understand and it is difficult for the preloader in the browser to understand what is being loaded. And by utilizing the static syntax in the module system, we can share the same security policy and host resolution policy, and get all the benefits of that and we get unified syntax that can use both in browser and server-side runtimes so it provides some API and when you run web assembly this is most common path because fact that there is most often very specific imports that need to be provided for the modules to make them execute. So it is needed above and beyond the interesting integration.
 
 GB: So, you get these benefits: static analyzability, and ergonomics and the sharing benefits. So the use case for web assembly we initially looked at if we could specify something similar for JavaScript, and the overall that design space looks like it can be figured out but in particular when it comes to JavaScript sources, one would need things like bindings and extensions and instances for it to be a useful feature and benefit to be able to have web assembly imports is that we have this WebAssembly.object, and so it helps us figure out okay, what is the shared base between these things that we can implement and specify so that we can share this concept of a phase and then use the learnings from those experiences to then do the extension JS. And the Wasm will help us out with this. And yeah, so, the – LCA do you want to take this slide?
 
-LCA: Sure. So what about the JS module source representation, and so Nicolo covered the module hook repo and this is what the module loader hooks proposal would like like and this proposal does not include this objects, so the module object constructor or the module source if  you understanding this is not yet useful and you can refer to the previous presentation on the discussion for the interactions semantics between this proposal and the module hooks and this will get eventually introduced through other proposal that has the concrete case for this representation.
+LCA: Sure. So what about the JS module source representation, and so Nicolo covered the module hook repo and this is what the module loader hooks proposal would like like and this proposal does not include this objects, so the module object constructor or the module source if you understanding this is not yet useful and you can refer to the previous presentation on the discussion for the interactions semantics between this proposal and the module hooks and this will get eventually introduced through other proposal that has the concrete case for this representation.
 
 LCA: Let’s get in feedback from the last presentation? One of the feedback that we got is that language features should use language objects. This means that the syntax production the import source production should bind, the binding should refer to a language value rather than a host object value. And the reason for this is to support for example, reflectability of what kind of object something and to be able to support features such as a shared binding object or a shared binding method between all sources that would reflect what kind of bindings a source has. So solve this, reprocessing to do abstract module source intrinsic and this is not exposed on globalThis, and this is a shared prototype of all module source objects and this should – one could use this implement module source reflection could add `bindings` method, and this is compare the compartments layers line proposal. And now this only has toStringTag. And the proposal requires that all module source objects to be returned by the import source phase imports to inherit from this class.
 

meetings/2023-05/may-18.md

@@ -175,7 +175,7 @@ MF: Yeah. Yeah. Which is something I would be okay with
 
 KG: That is way we could get out of order. It’s a bit weird. And it’s unfortunate in that like if you do `.map`, `.filter`, et cetera and then switch to out of order versions of methods, the subsequent calls are out of order. But the earlier ones are ordered. There’s nothing you can do about that
 
- JRL: Yeah. I think what SYG and MF have talked about answers my question. If we rearrange the order of these, then we can allow the consumer to choose their own semantics. What is required though is just that we allow promise settlement to happen in any order and then you can add your own semantics after that in either of these cases by rearranging the way you call the methods.
+JRL: Yeah. I think what SYG and MF have talked about answers my question. If we rearrange the order of these, then we can allow the consumer to choose their own semantics. What is required though is just that we allow promise settlement to happen in any order and then you can add your own semantics after that in either of these cases by rearranging the way you call the methods.
 
 KG: You can do that with map, not with filter