 OK, so what was your question? So how do you tell two variables or name equivalent? OK, perfect. OK, so the first thing that we were talking about before we continued recording is that the types, we don't ever talk about two types being name equivalent because here we are defining new types and giving them names. So that's the important thing. So clearly, they're all going to be not name equivalent because they all have different names. So here we're defining a type T0 as defined as an int. And here we're defining a type name T2 that's a pointer to a type T0. So type equivalence comes into when we talk about variables and what the types of variables are. So if we declare a variable x that is type T0, and then we declare a variable y that's type T0, and I said, can I do x is equal to y in name equivalence? Can I do that? Yes. Yes, because the type of x has the name T0, and the type of y, when it's declared, has the type T0. So those are the exact names. Are these eternal name equivalent? I don't ask the question. I don't know. Wait, did you say internal? Internal name equivalence. So are they structurally equivalent? Structurally, yes, right. Yeah, we did it here, right? Boom. Structurally equivalent, name equivalent, are they internal name equivalent? What's the definition of internal name equivalent? Yeah, that'd be a good thing to learn before the exam on Wednesday, I think. Indeed. So right now, I'm guessing that they're not, but if they were to declare in the same line, they would be. So internal name equivalence is similar to your homework, your project three. You created the type system, right? You probably gave each type some kind of internal name, right? So that internal name gets created when the type is declared. So here, we're saying, you can think of the compiler having a bunch of integers to declare all these types. So all the built-in types in whatever are types 0, 1, and 2. And then when it creates new types, it just creates a new type. This is type number 3, type number 4, 5, 6, 7, 8, 9, 10. The point is, these have the same name, so they must have the same internal name to the compiler. The name equivalence means, do they have the exact same name? Right? And internal name equivalence says, would the compiler give them the same name internally? Well, clearly, it would give them the same name internally if they have the same name. That's the way things got to work if you have name equivalence. But if they weren't, if they were unassigned, that would be different, correct? So let's look at this. So the question was, if we create a new type T9, we're defining it as an integer. And we have x is type T0, y is type T9. Can I declare x is equal to y under name equivalence? Oh, because no one's saying names. Exactly, they have different names. Even though the underlying type is the same, right, to the compiler, so think about it like this, right? Here's where you may want this. What if x is in inches and y is in centimeters? They're both ints to the program, but the programmer has declared, hey, I'm defining a new type called inches that happens to be implemented in type int, and I'm defining a new type centimeters that's defining a type int. And now, if you're using name equivalence, you're using that because you don't want to allow inches to be exactly. But they're internally named equivalence, though. No, different definitions, T0 and T9, right? These are two different types. So internally, they're not equivalent. Name they're not equivalent. What about structure? They're structurally. Structurally definitely equivalent, exactly, exactly. Okay. I guess I'm still not following, because, because you said when they send centimeters and integers internally, they're defined as ints. Internally, like the compiler would call them the integer. We'll use an int when it sees, like for the size of the integer for its internal representation. But in name equivalence, when you define a type, you're defining that type as an, you don't want it to be equal to something that's not that name. It's kind of like. That's name equivalence, but that's not that's not internal name equivalence. It's like turning, you have two fruits. You put them in the fridge. Those two fruits are technically still two fruits, but when you pull them out, you gave them two different type names and apple and orange. Okay. I don't know if that makes it harder. I know. I mean, I still am stuck on the internal name with the two types. So we'll see, we'll see. Because, so each of these, it's giving a different name too. Because you're defining as a programmer, you are defining different type names. So you think about like, when we had T zero and T nine here, right? So the compiler has to know internally that those are two different names. So they must be internal name, not equivalence. Just like before, when they had different names, when they had the same name, they were also internal name equivalent, right? Because the compiler knows internally that they have the same name. Okay. The difference where that comes in, so these are all us defining, giving a type, a new name. And we're constructing new types in giving them names. But we can also define anonymous types. So I could define X as, I liked using arrays more, but, right? I'm saying X is an array of integers. And Y, array of integers, right? So here I'm defining, I created a new type, right? This is a type constructor. I'm building up new types based on the basic types that they gave me. So this is a, does this type have a name? Yeah, array of int. No. Here I gave types names, right? Here I called it t0, t1, t2, t3. Exactly. Here I'm declaring a variable X that has a type array of int that I'm not giving that type a name. So it's an anonymous type. It has no name. So when the compiler sees this, it needs to create a variable X and create a new internal name for that variable X because it's a brand new type. Okay. Then when I see this Y on another line, I create a new anonymous type that just happens to be implemented as an array of integers. That's the type constructor. So when I say X equal to Y, are they name equivalent? Can I do that under name equivalence? Well, so there's still anonymous names though. So it makes sense to say they're not internally name equivalent because they're both anonymous types and the compiler can't show them, but now it doesn't make that array of int that looks like the same name. But I just said it's anonymous. How can I have the same name if it's anonymous? What does anonymous mean? It doesn't have a name. It doesn't have a name. Right? So can two things that don't have names be name equivalent? No, no. No. Well, you could do anything, right? Examples we have now are... No, no. All we're talking about under name equivalence is name. Yeah. Only thing we're focusing on is names. The only thing that matters is the names. Here we're defining types and giving them new names. We're saying, hey, I'm giving this pointer to T zero at T two. Bam, that's that name. And here, if you'll notice, we're actually using creating anonymous types in here. So here, this doesn't have a name. This doesn't have a name. Are they name equivalent? No. No. If they were on the same line. All right, we get that. That's different. Yes, okay. So they're not name equivalent. Are they internal name equivalent? No. No, because exactly, each of these is a different declaration. So these are on different lines. You're declaring different anonymous types on each line. Brand new type. Probably just never seen this before. It doesn't matter that they are, are they structurally equivalent? Yes, but it doesn't matter to the compiler. Okay, they are structurally equivalent. So now the question is, now the question is, so here I'm defining two variables on the same line. I'm saying variables W and X are both array events and Y is an array event. So, what's the name of the type of W? Doesn't have a name. It's anonymous type. This type does not have a name. What's the name of X? Doesn't have a name. Doesn't have a name. And the name of Y? Doesn't have a name. Perfect. So can I say Y is equal to X under name equivalence? No, because take it for me. I mean, sorry, W is equal to X. No, because they don't have a name. Exactly, they still don't have a name. Even though they're on the same line, they still do not have a defined name. Exactly. I'm the same with W, Y. Are they structurally equivalent? Yes. Yeah. Okay, what about internal name equivalence? No. Oh wait, no. Can I set W equals something? Yes, yes, because you put it on the same line, right? Exactly. So because there's one, so think of there's one definition of this brand new anonymous function or anonymous type, right? There's this new anonymous type here that we're creating and we're saying both W and X have that as their type, right? So internally, I have to create some new type alpha and say W and X are both type alpha. Now type alpha doesn't have a name, so it's not gonna be name equivalent, right? But here when I see Y, I have to give it a brand new type for this new type array of int that's this new anonymous type. So I'm the compiler. I need to give it some name. It's gotta have a name or something. I have to have some way to represent it. So I'll call it type beta and I'll say Y has type beta. So can I set W is equal to X in internal name equivalents? Yeah, yes. Yes. So internally is okay. Structurally, it's okay, but name, it's not okay. Exactly, so don't have a name. And is W is equal to Y? Can you do that with internal name equivalents? No. Exactly, so you have T alpha, T beta, boom, they're different. So the only way to have internal name equivalents when you have anonymous types is to have them on the same line. Exactly. Yep. Okay, but if you would have given, so yeah, I think we did talk about this, but just to be clear, so if you were to give them the same type names like T zero, T zero, and they were obviously name equivalent, they'd also be internally named. Exactly, because that's from here, right? So this is where that type is created, so. Yeah, cool. So it only gets tricky with anonymous names. Exactly. And anonymous types. Yes. If I remember that. I hope I remember that. Only there is this like concept in practicing all your life about how to like prepare and remember things for a test. This whole studying thing. Yeah, that's what I'm trying to get away from that though, because that's what the real world is not like then. Well, it's not true. We still need to study just different stuff. All right, thanks. Yeah. Should we do some closer? That was a good question. All right. Thank you.