Type Check Exercise

[00:00:00]
>> Richard Feldman: So once again, we now have a new section in here that we didn't have before. We still have naming parts tokenized from the previous section. And now we additionally have type check, which is what we're gonna also have these exact five for the next three exercises. So as with all the others, it's just like run node index.js.

[00:00:15]
So we just gotta see the inter there first. So we'll go ahead and do that. And as with all the others, we have a bunch failing tests and we're gonna resolve them by just finding this little finger pointing thing and figuring out what we should do. So, once again if you're curious about all this stuff, you can learn about it.

[00:00:34]
A lot of the things in the type checker, this is a lot longer than the other things. This is already 500 and by the end of the course, it's doubled in size to a thousand. There's already some stuff in here that we haven't talked about. So if you see unify, for example, we're gonna talk about that in the next section.

[00:00:49]
So don't feel bad at you need to understand that or you missed something. You didn't miss it, it's just like for the exercises I wanted to have, doing the actual type checking thing and that requires having things that we haven't learned about yet. But for our purposes, we're mostly concerned with jus fixing these small number of finger arrow things.

[00:01:05]
So in this case we're using the same terminology as we were in naming and this is what we're gonna be consistent with throughout here, which is just visiting a note. So when it was naming, we were visiting nodes in order to build up scope and detect whether we use things after they were declared and if we had duplicate declarations.

[00:01:23]
But for type checking, we're visiting nodes, because basically we want to populate the type database. So a really consistent thing that we're gonna be doing in this stage is basically just like working with type IDs in that type database. So the first thing we do here is be like, okay find the type ID of the parse tree node that is stored in node.init.

[00:01:43]
So const declaration basically has these three fields, so you have type. That's just the node type, so all the nodes have a field called type. The ID is basically corresponding to an actual like database ID. So it has a field called type ID, won't get into why this is an object later, but basically that is the field that if you wanna get the actual ID that corresponds to the database.

[00:02:06]
That's like zero or one or two or whatever that is, that's how you get that. And then finally, we have init, which is basically what is this constant initialized to? And that is another parse tree node. So this one's a parse tree node, this one is not. This one's just a database ID.

[00:02:19]
And then this thing is just saying I am a cost. So as the example if we had const x equals five, the parse tree node for the five part, that's gonna be over here init field. And then there's gonna be some type id that was associated in a previous step that we're not gonna work on in this exercise.

[00:02:34]
Something went through and assigned all of these ids to these. Okay, that's the first thing we gotta do is we gotta actually go find the type id and once we have it, then what we wanna do is we want to store that in our sort of type level scope.

[00:02:48]
So this right here, the scope concept works exactly the same way as we did in the naming section. The only difference is that now we're actually storing something with the scope entry. So I'm not just saying yes, this is in scope, I'm saying, I'm in scope, and actually this is my type id.

[00:03:02]
So now, you can not only go look up and ask the question, is this thing in scope or not? It was declared, but also you can say much more importantly, what is the type id associated with that? So that was how when we were talking through it in the slides, we were able to do things like associate like a with 0 immediately, without having to do the symlinking stuff.

[00:03:21]
We can just be like, I see it's in scope. Got it, that's what its type id is. So this is where we are actually setting that in the declaration, we're like, okay, cool, we need to modify the scope to say that is equal to the type id that we found in the previous thing.

[00:03:36]
And finally, we have basically just like needing to record the type id that we just added the scope inside the notes node.id.type id. And that's also gonna be a freebie, apparently. [LAUGH] But yeah, basically, this is the part where we're like, okay, if we want to write this down for later, it's not enough for us to say, we added we looked it up.

[00:03:58]
We added it to scope, we also need to add it to the node so that, if we were making a language server, we could do the hover to find out the id thing. Or much more importantly, for our purposes, we actually will directly need that later on when we get to web assembly code generation.

[00:04:17]
>> Richard Feldman: So let's go through our solutions here. So we had this visit cost declaration function and currently we need to do a couple things here. So one is first find the type id of the parse tree node stored in node.init. So, it's basically this thing right here, there's the type id that we need.

[00:04:35]
So [COUGH] the one other thing that we need to do is in order to actually get the correct node, we do wanna visit the node of node.init in order to get that back. So essentially, putting those two things together, we do const init type, or you can name this whatever you want.

[00:04:53]
But the relevant part is that we do wanna visit this node and go process it. And node.init is the one that we want here to go with its type id. Then next thing we wanna do is assign that type to the identifier. So for example, for like const x equals five, we wanna write down in this node what the actual identifier was.

[00:05:14]
So that's where the node.id.typeid comes in. And so we'll just put that right there next to this now that we've looked it up. And after that, next thing we wanna do is just add the actual variable to scope. So unlike the previous section when we were just adding it to a set and there was no associated value, now there is a value that we care about, which is that we wanna actually write down the type ID.

[00:05:39]
So after doing this, everyone who subsequently looks up in the scope, what is this particular constant's name? So a or b or x or whatever, they'll find out immediately that this is the type of that thing on the other side of the equal sign. I do wanna note that in some of the solutions, I have some bits and pieces included about, type annotations.

[00:06:01]
We're not talking about type annotations now, but one of the things about type annotations is that, and part of the reason we're not really doing them in this course is that they just kind of pop up all over the place. There's just a whole bunch of ways, there's annotation here, we gotta do this, and annotation here, we gotta do that.

[00:06:15]
And so you will see a little sprinklings of these things throughout the solutions where it's sort of like, okay, FYI, if we were doing annotation stuff, here is one of the several places where you would need to take that into account. But for our purposes, we're gonna ignore them, and we're gonna talk about them a little bit in a couple of sections from now.

[00:06:31]
Okay, and then finally, we return the actual type, because that's what visit const declaration does. And let's see how we're looking, fantastic, all the tests pass.