[Music] Huh? [Music] [Music] [Applause] [Music] What you just saw is a quirk in every single language. This is actually a subset of issues called linguistic ambiguity. If I'd had more context, I might have understood the original intent. But you know we don't always have those kinds of luxuries. Interestingly enough, programming languages face very similar challenges. We as programmers instead of communicating personto person are now communicating person to compiler. Whether you're coding in C++, Java, Rust or any programming language, compilers being a human-made invention are also imperfect at interpretation. This is why since they can face very similar issues, programming can also fundamentally be considered a linguistics issue. First of all, I have a question for you. I've got a very small program over here. What do you think the output of this program is going to be? We've got a few options here. First would be it prints out partially true. Second would be it prints out totally false. Or I guess a third option could be it prints out absolutely nothing. So, pause for a second and give me your best guess. might not be exactly what you would expect, which you probably got because I'm sitting here asking that as a question. So, let's go over. I'm going to compile my program. We're going to ignore our warning. I'm going to do /hm. We've got our answer totally false. Now, you might be thinking, looking back at the code, this really doesn't make any sense. I would probably guess that the output would be absolutely nothing. But instead, we're getting this totally false statement. And that's because this is part of a language ambiguity in the syntax called a dangling else. And we're going to get into a real world example of this a little bit later. Nearly every distinct programming language issue can be traced back to a very similar human language issue. In all these examples, I'm going to talk about the English language quirk and then I'm going to talk about the very equivalent programming language quirk and I'm going to kind of sort them into different buckets of the three distinct compilation phases which I'll also talk about in a second. Now, English in all languages for that matter can have a lot of different ambiguities and one of my favorite examples of this is actually a book from 1967 called Beyond Language: Adventures in Word and Thought. And this explores recreational linguistics. And actually, I think that would be a really good name for coming up with insults, like an official name. I'm not insulting you. I'm just practicing my recreational linguistics. One of the best sentences from the book, I think, is buffalo buffalo buffalo buffalo buffalo buffalo buffalo buffalo. Yes, that is a real sentence. Don't even question me. Just go look it up. But that's because the word buffalo can act as both a noun and a verb. But relating this back to programming languages with compilers, these kinds of ambiguities are even more serious and important to clarify. If you think about it, compilers need to be correct 100% of the time, but they also don't have the advantage of being able to ask for more context when they need it. Let's take a minute to think about how compilers actually parse the syntax of a program. Now, compilers have it a little bit worse off than humans because they have to do this in multiple different phases of parsing. And you can kind of break this up into three distinct stages. The first stage is going to be the lexical analysis. The second is going to be the parsing stage. And then the final stage is going to be the semantic analysis stage. So during the lexical analysis, it's going through and it's breaking up the tokens of your program. So like the variables, the operators, and it's parsing those out into distinct tokens. And then the next phase is going to take all of those tokens in your program and turn those into an abstract syntax tree or an a. And during that second parsing phase, it's this is going to be the part where it's finding all those syntax errors that are so irritating in your code, like if you forgot to add a semicolon or something in your C++ program. Side note, when I was in school, I remember I came up with the ten commandments of computing and the first one was remember the semicolon to keep it holy. Don't forget guys, during the final stage, the compiler uses that a and parses it to look for semantic correctness in your code. For example, it does type checking or maybe checks for scope resolution inside of your code. So if you have any kind of logical issues with your code, this is where the compiler discovers those. Like for example, if you're trying to use a variable that's out of scope. Now, if you're looking for a very understandable example of how a compiler works, I highly encourage you to take a look at the local C compiler, which is available open source on GitHub, and this is going to be a lot more readable than trying to understand a really big compiler like GCC or clang for example, that might be spread across like literally hundreds of different files. So, this is really well documented and easy to understand. I'm going to go over to the LCC GitHub repository. And just side note on here, this has to be the oldest commit I've ever seen in my life from 23 years ago. That's absolutely insane. That just blows my mind. I'm going to go over to the source code and you can see we have all of the different files that kind of make sense to put it into the three three different phases of the compiler analysis. You can see like the tree parsing it into an abstract syntax tree and you can see the process where it's doing both semantic and syntactic analysis. If you look at tree, I think it's very descriptive over here. You can see it actually going through and parsing the different op codes inside of this and then constructing that a so it can do the remaining analysis on it. Going back over to our linguistics challenges, let's think about how these ambiguities can come into existence. Now, older languages are going to face a lot of these challenges because if you think about it, you have an old existing language and you're constantly adding new additions on top of that. So, it kind of makes sense how these issues can happen. But this can also happen a lot inside of younger languages as well, which are also not perfect. I think a really good example of this is the word literally. Now, if you think about it in old original English, literally literally meant not figuratively. So it actually happened. But as English has progressed, literally has started to change meaning to actually mean figuratively. And a lot of people use it now as kind of a synonym for very, which drives me literally nuts. Now, now going back over to some C++ examples, let's take a look at them. And we're going to use C++ since that's literally the best programming language. Remember those three different compiler phrases I talked about previously? Let's take a look at each one of those individually. So for our first bucket, those would be syntactic quirks. And in linguistics terms, you could call this a grammar ambiguity, aka what happens if the same token fits into multiple different parse trees. And C++ has a really good example of this one, and it's very fittingly called the most vexing parse. Think about this English sentence for a second. Visiting relatives can be boring. Now, if you look at the word visiting, is visiting acting as a verb here, like the act of visiting your relatives, or is visiting acting as an adjective describing a noun, as in you're visiting relatives, can be boring. If you see, the word visiting can have multiple different meanings, completely changing the structure of the sentence. Now, keeping that English example in your mind, let's go over to a quick C++ example. So for this example, I have a very short program right here. I have a couple declarations up top. We have a simple function definition that's going to be declaring a function named m that's going to be returning a vector of integers. And then we have our definition for that function down here. Keeping that in mind for the next few seconds or or minutes pro probably seconds, I hope seconds. Let's go down to our main function and instead let's say I want to declare a variable. And we're going to name our variable n. And this is of type vector. And if I want to default initialize this with a few values, I can initialize this with let's say 10 values all initialized to the integer five. And if I go down here, adding a couple of extra values just because why not. And I'm going to be printing out the size of that vector as well as all of the numbers inside of it. So let's just run this for sanity and make sure this works. So we do slash vex. And you can see we've just got our vector printed out as well as the size just like we would expect. But now take a second and think, what if we didn't want to have default initialized values inside of our vector? What if we just wanted to have an empty n vector? You might think we can just get rid of those values. And let's do something like this for example. This looks right, right? But why am I getting some syntax errors over here? Let me save this and run this. We'll compile and you see doesn't compile. What's going on here? So if I go up here, I can see invalid range expression of type vector int. No viable begin function available. Well, that's very interesting. See what's happening. If you look at this closely, there is no difference in the declaration of this vector n as well as this vector m over here. So the compiler is basically saying, I don't know whether this is a function definition or a function declaration or if this is declaring a new variable for a vector of integers. This is an example of a syntax ambiguity. Now the way to fix this, let's get rid of this. It looks it looks really right. So if you're a beginner, you would look at this and you would think, huh, what's wrong? And it's probably why it got the name the most vexing parse. But the way to fix this in old C++ was like this where you have to set your new variable equal to a vector of integers. But this is just like the longest syntax in the world. But it does indeed get rid of our syntax errors. But if you go over to C++ 11, luckily in modern times we have this declaration option available. we can just use curly braces and it default initializes our vector to nothing. No default values, just calls the default constructor. And if we want to make sure that this does actually compile, got my dummy values down here. So we should have our vector size two. So I'm going to recompile. Let's run our vex. And here we go. Worked just fine. Now we can unambiguously declare a vector of integers as well as a function returning a vector of integers. Confused? Hopefully not. Our next syntactic quirk is going to be the dangling else, which we talked about briefly at the beginning of this video. So, let's think about this sentence for a second. If you see Sam, if he's busy, leave a note. Otherwise, call me. Now, this is kind of ambiguous, but it's mostly related to a punctuation problem here. Like what if I don't see Sam at all? Am I supposed to call you or not? So if we rearrange the punctuation and the structure a little bit and we get this, if you see Sam, leave a note if he's busy, otherwise call me. The meaning becomes a lot clearer. So this kind of ambiguity of association happens a lot in programming as well. Going over to our C++ example for our dangling else, I've got a really simple program here. Now, if you got the question wrong in the beginning of this video, now you have a second chance. If you can't remember what the question was, you should rewind and come back because you'll probably get this one right. So, we have in our simple program, this is kind of simulating a real world scenarioish of logging into a machine. So, we have a couple statements here basically saying like login was successful, login wasn't successful, and let's go to our main function. I've set this to is logged in is true. So, we're going to successfully log in and we're not an admin. So, we should not be able to log in as an admin. And then this is our nice little login check over here. And then at the end after we've logged in, we're going to get like a nice little goodbye message. So, let's take a closer look at this if statement. And again, tell me what you think is going to print here. I should have kind of a a boolean and over here. It should be if is logged in and is admin, then we're going to log in as an admin. Otherwise, we're just going to completely fail. So, if I'm logged in, but I'm not admin, I should really just be able to log in and then get the goodbye message. But let's go and execute this. So, I'm going to compile this. Ignore our warning. It's going to be the the phrase of the day, ignore all warnings. But what you see here, even though we should be logged in, we're getting a failed to log in. Get out. And then we get our thanks for logging in with us today. I didn't code that part. Great. So, what's happening? If we look at this if else, it looks like it should be working. Right now, what's happening is this else is ambiguous. It doesn't know whether to associate this else with this if statement or with this if statement. Kind of a side statement here. I honestly, personal pet peeve. I cannot stand when you don't use the curly braces. like always use the curly braces because what space are you trying to save? You're you're you're saving like a bite of space. It's just absolutely not worth it and it makes your code so much less reason readable. So, let's go over to the fix of this. So, I'm going to log in or get rid of this login right here. And if we fix this with some beautiful curly braces, we can make this so much less ambiguous. Now we know if logged in and is admin. We have our login admin right here. Otherwise, we're going to fail that login if our login was unsuccessful. So if I save this and recompile, you can see we've managed to fix all of our challenges with the ambiguous else association. All right, drum roll. It's time to look at our next bucket. And this is a whole different can of worms. It's not worms, guys. It's just monster. It's not even monster worms. So, for our next phase, remember the first phase of the compiler parsing was that lexical analysis phase. So, that's taking in all of your characters and parsing them into their respective tokens. But this parsing can be pretty tricky if you don't have the proper context to know what token some characters are going to map out to. Think about this sentence for a second. He said, she said hi. Now, we have the auditory advantage of being able to hear like my tone and inflection, so you can probably understand what meaning I'm trying to convey. But let's say you read this sentence instead inside of a book or something and you're looking at all of the different punctuation inside of it. In English, we have this concept of nested generics. So, this is really convenient for conveying meaning because you can have your single quotes inside of your double quotes to show what you're actually trying to say. Now, programming languages, especially earlier ones, faced these same kind of trickiness and challenges. Now, relating this back over to our C++ example, we can also have this kind of idea of nested generics inside of the C++ programming language as well. So if I took my previous vector of integers n and I instead decided to nest this with an additional type and make this a vector of vector of integers then I can put this one type inside of another type and nest this. Now this looks perfectly valid and it's going through I'm adding some different vectors to this printing this out once again. But let's see what happens when we compile this. And I'm going to go back in time for a second. And I'm going to go compile this with C++ 98. So let's do this. Traveling back in time. And something interesting is happening. So we're actually getting an error here. And let's read that error message cuz it's really interesting. So error. A space is required between consecutive right angle brackets. What does that mean? Basically that means that these two right angle brackets are being recognized as a shift operation. So this is going to be a shift write operation and the compiler during the syntax parsing process is basically saying I don't know whether this is a nested type or if this is a shift operation. So it basically can't tell what these tokens are supposed to be mapped to. And as our C++ 98 compiler is so kindly telling us, the old fix for this was instead of doing this, you had to actually add a space inside of here so that it could tell it wasn't supposed to be this shift write operation. And you can do this and recompile with C++ 98, but it won't accept any of my nice pretty syntax over here in my for loops. and you have to do this awful iterator syntax. So, I'm not going to put you through that. Instead, we're going to travel forward in time and go to C++ 20 and compile this. So, I'm going to have my original version cuz they figured out how to parse this properly eventually. And instead of doing C++ 98, jumping forward to 20. And here we go. We are we have successfully compiled this and we can execute this. perfectly fine. Wow, fascinating vectors. All right, let's move on to our next bucket. And this is probably going to be our worst bucket, and this is semantics. Now, context, context, context is so important here, but I think English is probably one of the worst languages for this since we just have so many overloaded terms. So, take a second and think about this sentence. Polish ambassadors are rare. Imagine you were reading this and you couldn't hear how I was pronouncing the word Polish. Well, since I have the capital P at the beginning, do I mean Polish or Polish? I would say Polish ambassadors are probably pretty rare. So rare they might even be non-existent. Now, through pronunciation and context, you can tell what I'm trying to say, but when it's written down, the only subtle differentiator that's not always available to us as a differentiator is the capital P. So consider this sentence instead. Meeting Polish ambassadors is rare. Now we've changed this so we're able to explicitly type cast the the capital P to the word Polish. So we can say for sure we do mean a Polish ambassador. I think I'd enjoy being a Polish ambassador. When I was a kid and I was picking chores, I'd always pick polishing as a chore. It's very, very satisfying. I don't think I'm qualified to be a Polish ambassador unless you guys will take me. Now, a great programmatic example of this is dependent type names. So, if I go over to my C++ program, you can see I have a simple function template right here, passing in a container, getting an iterator for that container, and then this allows me to print out the first element inside of that. If I go down to my main function, you can see I've got two different vectors. One is a vector of integers, and one is a vector of strings. And I'm able to call the same function and pass in those different types of containers. Now, if I go up here, let's focus on this line just a little bit. I want to try to compile this code and let's see what happens. So, I'm going to press enter. Oh, and we're getting an error. And the error message is missing type name prior to dependent type name. So, it's really complaining about this particular line. Now I want to copy this and let's go over to our CPP reference and look at our specific container that I'm using in this case which is a vector. And if I go down I can see part of our member types we have this const iterator available. Now if I go back over to my code you can see I'm expecting this to be a type const iterator. The problem is this right here. These two colons can also be referring to potentially let's say a static member variable. So the compiler is saying I don't know which one you're trying to do. And how do we fix that? We can be explicit about it just like we were inside of the Polish Polish example where we used the capital P in the sentence to distinguish that we meant Polish. All we need to do is simply specify explicitly that this is a type name that we're expecting. So save this and now if we compile our code comp compilation works perfectly and we can run this and see we can either print out the first element as 42 the integer or 42 the string. Sometimes the smallest tokens make the biggest difference about how a statement is parsed. Really good example of this is the humble colon operator. Consider this sentence. pack the following snacks, water, maps versus pack the following snacks, water, maps. Very big difference between the two interpretations. So the colon here is kind of like a whoop whoop to your brain of telling you what you're supposed to expect. Otherwise, in the second sentence, I kind of feel like I'm about to start eating water or maps. Not really not really the most tasty meal I've ever had. If you like C++, don't we all? then you'll know that the template feature is one of the most powerful parts of the C++ programming language. And much like the colon, the keyword template in C++ is an extremely important marker for the language to understand. If you use the word template, it completely changes the interpretation of the C++ compiler. Now, let's move on to our last C++ example. And yes, it includes templates. Going to go over to my program. I have a strct tool right here with a function template inside called perform action. And if I go down here, I have another function template. It's going to be our run processor that's going to trigger our perform action over here. And then I have a processor strct that contains my tool strct declared inside. And my main function is simply going to trigger this entire run processor process. How many times can I say the word process in a sentence? So, if I go back up, let's find the problematic line right here inside of our run processor function template when we're calling this perform action. Pay attention to this particular syntax right here. I'm going to compile this and see what happens. Now, interestingly, I'm getting an error here. It says use template keyword to treat perform action as a dependent template name. Basically, what's happening here is the compiler does not realize that this is actually a template. Now, it's looking at this particular symbol right here, our less than sign, and it's thinking that it is actually a less than sign, because it's not taking in the entire context of this, that we're simply performing an action on an integer. Now, how do we fix this? So, what we need to do is we need to be explicit with the compiler and tell this you need to treat this as a template. So simply enough, we'll just say that this is a template and then we can trigger our perform action template with our integer and run our processor on our tool ID 42. Makes a lot of sense, guys. Trust me. So I'm going to recompile this. Here we go. Worked perfectly fine. If I run this, perform action on tool 42 successfully. Being explicit is very helpful when you're programming. Now, I've been throwing a lot of shade at compilers in this video, but compilers are extremely complicated and super difficult to write. So, it makes sense why they would have so many ambiguities and syntax problems. I actually have an entire video that talks about like the history of compilers and how they can be self-hosted that you should definitely take a look at. But, if I'm going to be talking so much smack about compilers, I should probably try writing my own kind of compiler, which you can do inside of C++. So I have created my own custom parser for my extremely sophisticated language and this is called Remmbercript. So if I go over to my main.cp, this is going to run my Remmber program. So it's going to take in the input file that it's going to execute. And if I go over to my parser.y, you can see my extremely sophisticated parser. What this is going to do, this has a vector of strings that has really good song lyrics inside of it. And here are my tokens. I have my Rember token and my semicolon token. So, you remember that tokenizing portion of the compilation process. Here I have my own custom tokens inside of this. It's actually really cool that you can do this. I think it's really fun. Now, if I go down here, here's the logic for my interpreter. You can see every time I am encountering the Remmber semicolon tokens together I am going to print a random line of this song. Now let's go through and let's execute rememberers script. Now I have my repository here locally. I've already made my parser so I can run dot /erscript. It makes me laugh every time. And then I need to pass in my custom remember code. Well first of all let me show you. Let's cat one of these files. Let's do test remembermber. Every time you can see I've got my uh tokens here. Remember semicolon remember semicolon. So each one of these is going to print a random song lyric. So let's do dot / remembermber script and let's pass in test.ber. Here we go. We have our song lyrics that are printing randomly to the console. And if we want to get really crazy, let me show you. We can even do inline remember script. So we can do remember remember all in the same line. So let's execute this dot / remembermber and then we'll pass in our test inline remember. Here we go. Now we've got our three random song lyrics both in line and on separate lines. Tell me you haven't seen that kind of sophistication before. I really got to stop making these examples really late at night with no sleep and multiple monsters. I think this was only funny in my head when I did it. I don't I don't remember why. Anyway, all jokes aside, I highly encourage you to try to write your own custom parser in C++ because I think it's really cool to be able to do. It kind of shows you the challenges of it and it's just very powerful when you can write your own custom syntax. I think that's really nice to be able to declare your own tokens. Do you remember 21st day December always remember happy day? The real question is what can we do about all these different ambiguities and complexities in languages? And actually formal language theory is a really fascinating field to study. Now, although there aren't really many true examples of contextfree languages, we can get pretty close. And some languages are going to be better or worse than other languages at reducing these kinds of lexical complexities. A really neat example of this is ASD STE 100, also known as simplified technical English. And this was created by the European airline industry as a standard form of English for writing technical manuals in. And this was created to be a very easily understandable language for non-English speakers. You can actually find this language online. It's super simple and really neat. It's only limited to a total of about 900 words. As for programming, outside of toy and experimental languages, lisp and lisp like programming languages are kind of the clear winners here. Now, a lot of people really don't like the multitude of parentheses inside of lisp, but it makes it really clear and super unambiguous for the compiler. I remember my programming teacher in college talking about when she was learning to program and she was learning in lisp and she had to count. She was told by the teacher to count on her fingers opening and closing parentheses so that you could keep track of how many parentheses you needed to close at like the very end of a statement which is absolutely crazy. But other than lisp, ADA and hasll are pretty good about this. And while C++ might be my favorite programming language, historically it's not great at this. It's had a lot of lexical confusion in the past. So what do you think? In this video, I mostly stuck to C++ and English examples, but I'm sure there's a ton of other interesting lexical ambiguities in many different languages. So, feel free to leave yours in the comments section below. In any case, this is a super tricky field, but it's also very interesting. So, as always, thank you so much for watching everyone. I hope you enjoyed this video. to where he wired out.