Agoric SES, 3 Aug 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: SES Meeting: Layering Blocks

Description

Wherein Caridy shows us how well layering module blocks on first-class modules works out, and we discuss _at length_ how import.meta interacts between first-class modules, module blocks, and direct eval.

A

Okay, welcome to the s meeting today is august 3rd of 2022, and we have uh three topics on the agenda.

A

Charity has proposed uh a text that illustrates how the module block proposal is affected if it's built on top of a layer, 0 proposal, so we're going to start with a review of that and then follow up with the conversation continuing our conversation from last week on the signature of the module constructor and uh and then, if we get some time we can uh remaining after we make some choices about how we want to shape the compartment's proposal and whether to break it up into a epic of layers or saga of stanzas more on that later um karity.

A

Let's, uh let's, let's see your your changes? Okay,.

B

Okay, um okay, then share my screens. Hopefully you can see so nicola, and I we were talking about this and as a uh as a validation of what layer zero is trying to do uh how other proposals, like motor block, will be able to built on top of layer zero.

B

So he was supposed to do this, but he's on vacation. So I took a stash at it and um it seems that it's um coming together very well in a sense that there is only two meaningful changes in the spec that needs to happen to support module blocks. The first one is obviously having a new syntax specified there.

B

The the second one is to define the runtime semantics uh evaluation, semantics of module block um and when you start looking at this code here is quite similar to what we do in the module constructor uh this one, uh the module, constructor percent module percent.

B

um It's very similar to that in a sense that what we're doing is, let's get some uh referral, which in this case will be either in a script or a module. It could also be known. um There are certain instances in which this might be known, but I don't have all the details there, I believe. Is it the on click on an html element that can give you a an old referral?

B

Something like that, but you get the referral and then, with that referral, what you do is basically um using that referral to resolve the same way that you resolve today, anything that represent and specify associated to a module.

B

So basically, you use a referral as a closure to create an import closure function that allow you to um delegate the the resolution of anything that depends on that module block. uh Sorry, anything that the module block depends on. So this is very similar to what we do. The difference is that in the module constructor, we can look at that. We don't do this one.

B

We do the new mechanism to resolve the module intents, because dependencies of module instance must be depend uh must be modulated itself, which is different here here, we're resolving to um a module. That is not necessarily a module in terms. It's just uh the same mechanism we use for dynamic import basically, um so this is pretty straightforward.

B

As for the source very straightforward, well, we created a source module source intent. We get the body that was provided via the the module body was provided via the the the syntax, and then we parsed that source and we we um yeah. We, we parsed that and we had attached to the internal slot of the module source. Intense the same. We do for the modules, so we ended up returning the module intense down so very straightforward.

B

The only thing that is up for discussion here is this one here, which is a host initialization module block, which basically saying I have a new module report and I have a ref a referral.

B

Do whatever the host needs to do in order to accommodate things that are needed for the module record to work, and this specifically, I can think about two things there. First, this mechanics can define um the host define field associated to this module record. It can also define the.

B

Where is it here? You can also define the import meta fields that you might be able to inherit from not inherit, but you will be able to copy them from the from the referral. So, basically, when you do a module block, the module method, you're gonna get is exactly the same as the module method you get outside of the motor block.

B

It's the same thing, um so this will give sufficient information to the hosts to do the wiring between the two records to try to associate the two records in a way that when you ask for the meta, you can build that meta object for the for the motor block uh intents um and that's it um this other one is just one change of one of the abstract operations from the layer zero. I believe we can get away without this, so I'll probably make some changes there to accommodate this. This is just uh unnecessary.

B

I would say so once I make that change. This will go away and really the new spec will be just simply the definition of the syntax and the runtime semantics of that new syntax and that's it. There will be nothing else and then the whole initialization block, so it's very, very simple: the tricks that we came up with, which was the creation of the closure as the input hook.

B

So you think you see here in this line line 10 step 10, you see, we create a function built a built-in function out of this definition of disclosure. This is what gave different entrances, the ability to behave differently to resolve their dependencies and that's the trick. We have these internal slots that we use for resolving the things that you need.

B

So when you do import on these interns that is returning here, they all it's just going to look at the input hook and try to go with that to resolve the dependencies and then initialize the the module. um So that's pretty much it there's really not much um compared to what we have right now there, uh if you're going to see if I can get to that, if you go into the current spec, which might be linked out from here somewhere.

B

Maybe I can just get it from here.

B

If you look at the specters- oh no, this is not it all right.

B

Well, it's you we can. We can look at it at the deep. The deep is huge like where we have um so it's basically removing the majority of the spectex that we have in there. But it's a lot of red in here that we don't necessarily need anymore, because the layer zero does that for us.

B

So that's pretty much it. uh I think it's a good validation. I think uh it gave us more ammunition to continue this path, making small adjustments and then then we can go from there.

C

B

C

Sure I get the punch line right. The um uh the total implied changes to layer. 0 itself are what.

B

Layer, 0 is, um is here so it's, it has a couple of modifications on the current spec one runtime semantics, one new.

C

No, I meant in order to accommodate, given layer, zero the layers here that we had before this exercise in order to accommodate module blocks on top of layer zero. What changes do we need to make to layer zero.

B

No there's none, there's one that I'm proposing only one. Let me see if I can find it here, um which is that the this parse module source, which produce a a record, called now a a a module sort of record, which is a new kind of record, which is just for the an artifact. So eventually, when you know it's a sort of text model record, you just copy those things into the source text module record. So that thing that does that is expecting right.

B

Now, it's suspecting that source text only got it, but the source text is not a thing that it will receive now with this runtime semantics, because we already have the parse code. So in that case we just need to modify this method to allow not only receiving the source specs but also parse nodes.

B

What I would like to do instead is that this thing only receive parse, so the name will change it receive the parse nodes and, depending on where you are, you can parse in here. You already have the body that is parsed in the layer.

A

B

Where is it it's layer, 0 constructor, in the module constructor here, rather than calling the.

B

Rather than calling the, where is it um here, motion source, rather than calling, let me say, harsh module source? What do we call that uh we call it here so rather than calling this thing here, we parse this first and then the result of that is what we passed to the abstract operation, so that.

C

B

We simplify that even more, and it seems that you will have different ways to get your hands on on a parsed node and then what you need is just extract. The metadata out of the parse node and create its record.

A

That's that's consistent with moddable's needs as well. I think.

B

um So yeah so, but I I think the important part is that it's very, very, very, very similar. There are still a couple of things like this one resolved to a modular record, um a source tax model record.

B

We don't support that in layer zero, but I think it's we are in debating that part still uh nicola, and I um so whether or not this this should be sufficient, uh but I think we can accommodate.

A

Yeah, I think that the only thing I have to say about like so for I mean first foremost, this looks fantastic. It's your the punchline is fantastic. The um the large point that that the layering is going to work well for these proposals is is fantastic.

A

I think that on two top one runtime semantics and evaluation step 11 for performing host, initialize module block.

A

That is dubious because that needs to be virtualizable.

A

But this is only for a module block definition, so it doesn't have to be virtualizable. It just needs to have well, we need to have a. We need to come up to the end of a conversation about what we want to do about threading, import, meta.

B

So on that, on that note, I think I had a note here. I I think I added node at the bottom of it. Let me see if I can pull it up so so, who? What can this be? uh The? Let me see what this referral can be and it can be a no. It can be a script which, in those cases, you will not be able to visualize that thing um if it is a module record, that is, that does not have an associated module intense. So it's not derivative from the module instance.

B

You will not be able to visualize that, but if this thing is a is a is a modular intense. Basically imagine that I have a module block inside a source that I create using new module source, so the intense that is the referral of it will be the intense, a modular record that is associated to the intent that you create off of that source, and so in that case, the the virtualization will be, as you said, complicated, because this really the host doesn't know much about it.

B

So that's why I had a comment at the end here saying that it could be a module record associated to another module intents which in, in which case the meta. The incremental field can be copied over or just.

A

Passed is another, just just shared is another possibility.

B

Yeah yeah I can. I can probably one thing that I might be able to do, and then now you mentioned, I can add a new step before this one, which is some just simply saying. If the referral is a module record copy, the value of the import meta into it, that value can be set or could be undefined and either way it works.

B

If it is undefined when someone access it, it will create it by the host if it is defined and it will use it uh and therefore you get you get the the thing that you need, so it might be might be easier to accommodate that in such a way that we can still call the whole initialized block, but doesn't do much for things that it doesn't know.

A

Yeah, I think that that would that would produce the behavior that I, like.

C

I'm not understanding why we need a new host hook at all. Why we can't define what it is. The relation I mean, the module block is the you know the semantics of it has to do with its relationship to the module that contains it. Yeah the module contains it. If it's created with a module constructor, then the referral- and you have me pronouncing it- referral now. Referral and import meta is passed into the module constructor parametrically without anything needing to look at it. No.

B

So so here here's, why mark when you access the implement assuming.

A

B

Have a a module assuming that you have a module that or in a script or a module or a script, and you have a module block inside that.

A

B

um And so at this point, you're not creating any any intents in user lab that are created by the host by normally by language, so the language is creating that intent for you and the other data. If you access the implementer from within the module block, okay, you're gonna get into this. This is the runtime semantics for input.

C

But but I would say that the place where you got into that semantics is what the binding of import.meta is in the containing module and then it's simply the same binding for the module block.

B

Yeah, this is just the syntax runtime semantics of the syntax, so input of meta will be computed during the runtime semantic, the evaluation of it and when the code needs to evaluate that syntax, it will get to this astra this. This is from time semantics and it will basically attempt to get the associated module or a script which in this case it would be this the module block. So this is going to be the module block from that module block.

B

It would try to see if the implementers are defined um and then based on that it will decide to create it or not and when it creates it it, it asks the post to create it, because, okay, so.

C

So I'm suggesting that the host decision point should only come much earlier is what the host contain, creates the containing module.

C

The host decides, what referrer identifies the containing module and um and what import meta is in scope in the containing module and then, when the containing module evaluates a module block expression, then the module block expression just inherit without does not you know, there's no more decisions for the house, there's no more invocations of a host.

C

Everything from there on is just defined by the language spec. Well, so.

B

Right now it's lazy, so they don't do it if they don't need to.

C

B

C

I'm suggesting don't mean: is there any observable difference between it being lazy and not lazy? And if it's not lazy, then we force the decision to be made earlier um and that just results in a cleaner spec. Because now the semantics of the module block is not up to the host.

A

Essentially, we could, we could do something similar to it.

B

I'm still confused, I'm still confused, because the module block is subject to the host, in the sense that um if the example that I was given like as a module evaluated by the host, your script type module. Something like that and you have a source and there's a module blocking that source, the import methods of that don't need. You don't have a way to virtualize that, because you're, not instantiating, that intense, that's right, the syntax is doing that.

B

So the import methods associated with that motor block are handled by this by the host, not by us yeah. So.

C

I'm saying I'm saying that I'm saying no, so I'm saying that the the host should determine what the what the binding of import meta is when it evaluates the containing script.

A

um Maybe I can help with this, like maybe I I think that what mark is suggesting is that we accelerate the runtime semantics of evaluating import meta to the point at which a module block is evaluated.

C

No, I'm saying that that uh the oh I'm sorry, the the the evaluation of of the import meta expression, but the binding the value that it evaluates to.

A

Should be passed directly to the module block priming its import meta internal slot, so that we never visit uh the body of step. Four.

C

And without at that time, uh involving a host hook.

A

C

Okay, where it's just it's deterministic by the language that the host hook only intervenes when, when first evaluating the outermost source unit, the the outermost script or the outermost uh module.

B

I would say that that would be no goal for implementers. I'm not an implementer and there's.

C

If it's not observable, if it's not an observable change, then um in terms of what implementations need to do now, then it's not an implementation burden.

A

uh I think I know a reason why implementaries might bulk, and that would be that. Oh no, we could.

B

Yeah yeah, I mean you, you.

A

Doesn't yeah yeah so so let me put it this way is that the the module block is for one, the module block might never be used, um in which case instantiating import meta is a burden on the runtime um and then also the the module block may itself never utter import meta, in which case there's no possibility that it would ever be used at all yeah.

A

um But that is.

B

Which they can do all they can do all that by looking at the record, the record says if they haven't implemented, I mean.

C

I think, if we're about to, if we're going, to make any compromise at all, to accommodate the optimization of dealing with code that doesn't say import meta, the place to put that compromise is to is the static api of the source record is to just have the static api of the service record say whether the thing mentions import meta, yes, and if.

A

You do it there.

C

Then you don't need to do it anywhere else.

B

Yeah, so I I'm still I'm still fosse about what what would be the motivation of this change in behavior, the.

C

Motivation of this change is that the language is much more deterministic is giving the host far fewer choices.

A

We do not want to give hosts the latitude to populate the import meta of.

C

Of the contained block to be different than the containing module.

B

I mean one way to do it. One way to do it without pushing pushing them to do that, for all records would be that we could. We could come here. We could make this a transfer operation this one, not the the sub block this one.

B

Here we make this an abstract operation, and then we call this operation here uh and we call the same operation on the module blocks here to compute the meta for that referral, and then we copy that into the import meta internal slot, and that means that if you have a modular source, the meta will be the meta that was compute for once upfront ahead of time by the by the runtime semantics of the in the referral, so that that might be easier to digest for them.

B

Because then they can say: oh yeah, when you have a, if you are a module source module block into your code, that immediately triggers the creation of the information upfront during parsing and evaluation during evaluation, and that might be okay for that. Well,.

C

Sorry, if you have a module block expression inside the source, then the text of the module block expression is also statically there and if it doesn't mention import meta, then the module. You know if nothing in the module, including the nested module blocks, mentions import meta. Then the module as a whole has not mentioned in part meta, and you don't need to compute it right.

B

Yeah, that's what this is supposed to do. They host initialized monitor block by the way it gets a referral. He gets the record. He decides whether or not he has to do anything upfront for um whatever you name it like it doesn't really matter whatever it is.

C

Okay, but that's that's only for the outermost source unit, right the uh if, if an inner source unit says import meta, then the.

B

Inner source- they can know it at this point, because this is here, the module.

C

Has that information.

B

What about eval, eval.

A

Doesn't get you.

B

Access to import meta.

A

No, if you, if you eval and there's a module block inside of the source text, that you're evaluating.

C

Oh god directive l you're talking about yeah, oh.

B

uh I don't know I don't know, but this one can't resolve to know. Basically god, oh my.

C

B

This one, this one can't see.

C

B

C

Must have already come up for module blocks is. If you can have a module block expression inside a script, then you can have a module block expression inside a script, that's being directly valid inside something else.

B

Yeah, it's like like it would be new, so I think it would be new um because well, there is a execution context at that point.

B

Is it I don't know, but it certainly can be. You know the result of this operation can be known, meaning you might end it up with a referral that is new and then basically kind of a global, but.

C

So I think of one you know of all the ways to it to explain: direct eval, uh the one that I've had the most most success with um as well as you know, for under explaining it to myself uh is uh as an unquote operation that whatever the string is. That's the argument to the directive, l, it's as close as possible to as if that string had appeared lexically in the in the source instead of the direct eval expression.

C

If you it, you know it evaluates almost as if you had just spliced that string into the containing source um uh uh and we've already made a bunch of exceptions to that, and those exceptions are are there. But in general we try to inherit as much as possible across the directival boundary that we would have inherited across a block boundary.

A

That would pre and yet no- and I believe that this is you're you're, leading to that the that the referrer would be inherited by the directly evaluated code.

C

Yeah and the import meta.

B

Yeah, I think we're good we're good we're good mark, I think, even if it is inside the evolve, uh direct or indirect evolve. No, no just.

C

Just direct indirect is a completely different case.

B

So the direct evolve, I believe, will be fine, because you will have an execution context. You will be able to find that execution contact. You will be able to find the topmost execution context and and you'll be able to find that is inside. This eval is happening inside a module record and you will result to that module record there, so it might be fine.

B

At that point, I will have to update that, obviously with the test or something, but for what I see here, it will be able to determine that you evolve is happening inside a module, a module uh source decks that has a module module.

B

Module record associated to it and they will be able to resolve that to that module record.

B

Because there is an execution contact, it's not empty.

B

um There is a topmost execution contact as well, which is the outer one of the evolve, and they will be able to get that and determine whether that's in a script or a module, and they will determine that it's a module that is doing eval or a script that is doing evolve. They will be able to link to that. So I think we should be fine.

C

Okay, it's funny how direct deval always takes me by surprise whenever there's a new piece of semantics and then the directive out question comes up. It's always! Oh my god. I didn't think of that.

B

Yeah, I was testing that the other day uh doing important meta from from front eval and he throws.

C

Oh because import.meta in a script throws so so the the real question doesn't come up until you have module blocks because module blocks lets. You have a module textually within a script and therefore as something that a direct eval can evaluate.

B

Yeah, it's still still. We have that issue that I just show here in the console. Let me show you: let me do it here. Let me make it bigger.

B

So if, if you have a module source right here in a script- and this is doing import meta here somehow um this will be problematic because I'm not problematic, they need to figure the host needs to figure what the implementation will do in that case, because if you do import meta in a script, it will fail. So it's saying: oh it cannot. It can only. It cannot be used outside of the module right, but you will be inside a module because you're doing you're doing this so.

C

B

The what is the method for that? uh You cannot say the same message because you're inside a module, but you don't have a referral. So in that case I believe it will be the same mechanism that the holes used when you do something like an script.

B

A script source, yada yada type, monitor where there is no referral at that point and they still be able to construct a import method. So that's why it is important to still have this thing here in my opinion, because they give the host the ability to decide what the implemental would look like, but the refactor I mentioned um might be problematic because by the time you try to do this operation, uh there will be no uh referral.

C

So actually this this comes up already in the current spec, and the current current implementations must do something. I just noticed this, uh which is, if you're in a module- and you do exactly if you, if you're in a module a then if you did a.

C

Dynamic import expression within the module, a that dynamic import expression would be conditioned with a as the referrer.

A

C

So if you're in module a and you do a direct vowel of a script containing a dynamic import expression, normally, if you have a dynamic import expression inside a script, it has no refer. But if you have a direct vowel inside a module where the directive val is evaluating the script that has a dynamic import expression. What's the referrer.

B

Yeah it's this one here. This is the same mechanism, so that part. I think that part. I'm convinced that this is not a problem, because you're gonna hit this and we can. We can look at the import semantics I think, is somewhere here close here. You will see that we use the same mechanic, so it's here so you're getting when you do dynamic input, you're, getting the active module and that works fine, so that that part is not a problem.

B

What I'm saying is the problem might be that if we don't have I the problem could be that if you want to compute the import meta here for the referral, the the the the browser in this case has to intervene and create that for you, because I'm sorry, you said the import meta.

C

Of the referral.

B

Of the referrals we were saying, actually I should type in I mean there's.

C

An import, meta and there's refer, both of which.

B

So I'm talking about this one here, so I might be able to do something. Like said, oh no, sorry, I said um this is a module record, dot, m4, meta b sum abstract operation.

B

Let me call it create, create meta or you put here, the referral, which is this one. Okay,.

B

So you do this all good and dandy, because you have when, when this is a modular record, but if this isn't a script, it might be problematic uh again. uh Someone has to call the host at some point, you're not going to escape that.

C

So so so so when you say script I mean, I think, we've just convinced ourselves that there's two script, cases that need to be distinguished, there's a direct there's, a direct vowel that is in a module where the what the direct vowel evaluates, is always defined as a script. But that's still happening as a direct eval inside a module and then.

B

There is no, no, no, no, no! No! No! No! No so again like that part is fine, because this one so.

C

You're not talking.

B

About it, this one has rewarding for that. The warding is here, it's saying the.

A

B

uh Context stack is empty; no, it's not empty. Okay, execution context, good top, most execution context on the execution context stack whose script module component is no is not new. So basically you go up until you find something that is a model or a script, and you get it good good. So.

C

This this goes with mine, okay, it goes along with the principle that all of that the host decisions happen for the outermost sourcing. Only.

B

Right, the problem, uh the solution that I was proposing, which was let me go back to the solution I was proposing. The solution was that we can make this an abstract operation. So as long as you have a modular record, you can call the disaster operation that produces the module meta and it does hose. Operations are fine, but you always get this module mental that you can cash at the module record level.

B

That was the proposed solution that proposed solution fails, because the referral that I have is not always a modular record and because it's not always a modular record, I have no ways to um create what I need without talking to the host.

B

And as a result of that, um I I feel that they have when they, because they they say, okay implement, that is happening always inside a source. Look at it step. Two is saying it has to be a source text, module record uh fine.

B

That is fine, otherwise it throws, but the they have internal information associated to that record. That allows the host to make determinations what the import meta should. Look like. Okay,.

C

uh So I just realized that um this step the static uh part of the the source, this the source text, module record api. That says, does it contain an import meta that should be something like might it contain and import meta where it's true either. If there's texturally and import meta or there's textually a direct develop.

C

If there's textually a direct devel, then it you can't tell statically if it does contain an important meta, but but by virtue of the fact that you can, you can statically tell that there's a direct vowel you can statically tell there might be an important.

A

B

I didn't quite get that.

A

uh So currently we have uh in in the compartments proposal, there are property, there's a property needs import meta and the premise has been so far that you can just syntactically analyze. You can statically analyze.

A

The content of the um of the module to see whether it uses import meta, syntax anywhere mark is mark's point is that that is not sufficient, or rather that needs meta must be true either if there's an import meta, syntax used in the module or if there is a direct eval that might use import meta, um and I think that syntactically yeah, if there's a if there's a direct eval node in the syntax tree that needs import, needs to be true. Basically, oh.

B

Because direct evolve does not allow you to have import meta there. It fails.

C

uh If there's a dir, what I'm, what I'm suggesting is, if you're doing a direct eval inside a module and the dir and these the the direct eval, the you know, the syntactic unit, the direct deval evaluates is a script, but now with module blocks proposal, the script can textually contain a module block the mod that the module block could have an import meta. So now it's possible for the direct deval to evaluate a string that that contains an import meta.

C

Therefore, in the containing module, if there is a syntactic direct vowel, you have to say that the containing module might contain an import meta.

B

A

B

But that's only that's only.

B

Yo I'll need some. I need some helpful implementers here about what what to do, which is if it feels to me that.

B

Eagerly creation of implementation might be problematic.

C

uh It's uh you're only uh so eager creation, even if it's only for modules or your top-level source units that contain either an import, meta expression or a direct eval expression. In no other case, do you need to create it at all.

B

Right so I get I get it. I get why the direct evolve might be problematic because inside the directive you might have a modular source and that module source might need to get access to the input method of the outer one. Yeah.

C

And then all the implementations already buy into the idea that directive l puts things on. You know, directive, outputs things on a slow path. Nobody tries to keep direct development on that fast path.

B

Right but remember that the remember- and this might be problematic in a sense that it's very difficult- I I don't know any artifact of the spec that today allow you to um accurately predict the presence of a direct evolve.

C

No, no, no, there's that the the there's a direct avail, syntax right! That's all that I'm talking about is whether it's actually a direct eval or not depends on the runtime binding of the uh the lookup of the eval identifier right.

B

C

So so ignore that uh only if it textually contains the direct eval, syntax or it textually contains the import, meta, syntax.

B

C

That's the switch and to to eagerly compute the import meta for those cases and no other cases, I think, is all the optimization you need. You don't need to be lazy. If you do that, if you have that conditional.

B

Let me see, where is that, thank god.

B

Where's that uh record, I don't think we have it right now. I.

A

B

Think we haven't yet.

A

B

um Yeah, I don't think we have that detail, but we have talked about having that detail specified somewhere. Okay, similar to these are the things that we have in here uh like this one, whether or not it has a tla, um yes and garage.

B

So we're talking about adding a new internal slot, a new field to this record source text, module record. That says whether or not you have a implementa and.

B

Okay, yeah and that value will be will be basically whether or not you have a directive or you have imprometa in the source, correct and uh and with that information you will be able to I'm trying to um build momentum here. Sorry give me a second, so with that information you will be able to make determinations.

B

You'll be able to guarantee that you can build the import meta associated to a module record.

B

um If, if that value is true, you might be able to do it up front or you might be able to do it lazy, so you've got, we can decide and respect when to do it lately when to do it uh on.

C

The reason it's important is that if you're doing it lazily and you're calling out to the host to do it, then the host becomes active and can make decisions at the time that import meta is evaluated, whereas if you're doing it eagerly, then all of the host decisions are up front when it evaluates the outermost source unit.

B

C

That's the case today.

B

They are they're doing it lately when you evaluate the implementation.

A

Right but they don't know what to do, but today there aren't any virtual modules.

B

A

Bitcoin modules.

B

Are different? Virtual modules are different because video modules you have to create an implement upfront. You already have.

C

If there's no observable difference with regard to the current language, then the change in the way the language states, the semantics, does not require any of the implementations to change. It just lays different groundwork for how we change the language.

C

Right, you can always languages, do lazy, optimizations of eager semantics all the time, but when they do that, it's not the host, that's being called it's. The implementation, that's being called so a way to describe what the implementations are currently doing is it's as if the host had made all of the host discretionary decisions up front had told the implementation what to lazily compute, but it hadn't actually computed it yet and then later the late, the implementation lazily computes something, but it does it in a way.

C

That's transparently lazy, there's, no observable difference between doing it, lazy and eager.

B

Okay, so let me step back a little bit because sure we will do that. You still have to call the host.

C

Right, but only when you're evaluating the outermost source unit and, at that point the host after that point, the host is out of the picture and it's only the interaction.

B

You have to do it for the for the module block as well, because the module block retains certain uh hose defined behavior associated to where that module block was declared.

C

Now, what I'm saying is: it's you don't involve the host when you evaluate the module block you when you evaluate the module block, the module block deterministically without any host discretion gets from its containing lexical environment. The bindings of those things.

B

Yeah, I have to think about this and talk to some people, because the way I was thinking.

C

About this is that.

B

The whole still wants to retain certain capabilities on that module, so the module block, because first we don't know how that's going to be played out in the debugger and so on the csp associated to it. I think that one's not a problem, because it's already parsed, um so there are certain things that might be needed. Anything. That's only.

C

Observable by the debugger hosts can do whatever they want without any problem of conforming to the language spec. The issue.

B

Is you have to give them that you have to give them their hooks for that.

C

But those aren't those are not post hooks in the specification sense, because there's no observable consequence to programs running in the language of what the implementation does to communicate with debug. So it's not the host in this in the 262 sense of what a host is.

B

So it's here's. The problem uh defined uh sorry hold the fine, so for a oh, I'm sorry uh typo given so when does the so first of all, the first question about this is: does this module block what requires to have a host defined internal slot being said, that's number one and number two is: when is that value going to be set?

B

The way I specify this here is that I'm doing it here and giving the host the ability to not only act on the input meta, but also act on the module defined.

C

Okay, if the only thing the host can do is set the host defined field, where the host defined field is never used by the specification for anything, and obviously it wouldn't be. That's the that we do that consistently with the host defined field. If the only thing the host can do is to set the host defined field and everything else is determined by the spec, then that's fine.

C

I think that that in fact we could erase all of the host defined fields from the language and the implementation would still feel free to add host defined data to all the records it wanted to, because uh if it's only using it for semantics, that's outside of what's observable in language, the language itself didn't ever even need to mention the top. The existence of a house defined field.

B

Okay, I like that you still have to provide the two things, though, to that hose uh asteroid operation, you need to give the quorum on your record and the uh referral.

C

B

As the only thing that I do.

C

B

C

Long as the only thing the host gets to do is set the host to find field as long as the host doesn't get to do anything. That's observable by programs running in the language, I'm okay with that.

B

Okay, so that helps because uh here we have a question and nicole- and I were going back and forth like what to do with the hose defined when you're creating an intense uh from a new source module module source and and we can, we can defer this set it to undefined, and then we create the intense we can get the referral uh and then give it to the host, so the host can define whatever they need to define in that case, but, okay, okay, I think I have sufficient information now.

B

Let me let me work on that.

C

Yeah as just a good donkey experiment, if somebody proposed a a a change to the spec, where every time the language created a function, it called out to the host to add a host, define the value of a host defined field to each function. So each function had a host defined field and there was a call out to the host for the value of the field on each function. Creation that would not be an observable change language.

C

So if you can add host defined fields everywhere and add host hooks, whose purpose is only to populate them everywhere, without making an observable change, then you can also erase all of them without making an observable change. Okay,.

A

All right we're at time um I'm going crazy.

B

Sorry, can you open an issue somewhere, so we can track the? We don't forget and we can track the um the new field on the module record or whether or not it has it needs a meta because we don't have it yet anywhere, not layers they're, not not nowhere else. So we need to keep that somewhere. So we can go back and do that.

A

Let's, uh let's chat out of band and figure out where to put that? Okay, all right um so next week, we'll continue with the signature of the module constructor and whether to break the proposal up into separate proposals in an epic all right. Thank you. Everyone.