 The basic units of action in our code are called operations, and just like in mathematics, an operation is something which takes input values and then returns an output value, like say, an addition operation with the inputs 3 and 5 returns the value 8. In an operation, the part which specifies which operation to perform is called the operator, like say, the plus sign in an addition operation, that's the operator. The input values to the operation, those are called the operands. So here's an example addition operation as you're used to seeing it in mathematical notation. The plus sign is the operator and the operands are 3 and 5. In Pigeon however, we use a slightly different style of notation for operations called prefix notation. The notation you're familiar with from mathematics is called infix notation, so called because the operator is infixed between the operands. In prefix notation, the operator is placed in front and then the operands are listed afterwards. Another change we make in Pigeon is that the operators of common operations are not denoted by symbols, but instead are denoted by words. For example, the addition operator is not the plus sign, but rather the word add. So rather than writing 3 plus sign 5, you would write add 3 5. One other important change with this notation style is that the parentheses surrounding operation are not optional. Every operation is always surrounded in its own pair of parentheses. In infix notation, the parentheses are often optional, like say we can write 3 plus 5 without any surrounding parentheses. Now one advantage of prefix notation is that operators are not limited to having just two operands as they are in an infix notation. So whereas in infix notation we have to write 3 plus 5 plus negative 7 plus 11 to add all those numbers together, in prefix notation we can simply write one addition operator followed by all four operands. Another advantage of prefix notation is that we never have to worry about precedence. With infix notation the operators are given an order of precedence, that is a set of rules that determine which operations are performed before others when parentheses don't explicitly denote the order. So here for example, when you write 11 minus 2 times 3, the multiplication operation is performed first because the multiplication operator has a higher precedence than the subtraction operator. Really the only point of this order of precedence is that it often spares us from having to explicitly surround our operations in parentheses. We only need to use parentheses in infix notation when we wish to subvert the normal order of precedence as we do here, where we put the subtraction operation in parentheses such that it is performed first before the multiplication. In prefix notation though, there is no concept of an order of precedence. We just always explicitly put every operation in a pair of parentheses and there is never a question of which operation is done first. Here for example, you see the prefix equivalent where we have a multiplication operator with two operands, one of which is the number 3, the other of which is another operation, the subtraction of 2 from 11. Last thing to note here, with some operations like multiplication and addition, the order of the operands doesn't matter, but with other operations like subtraction it does. For instance, sub 1112, that returns 9, but if we wrote sub 211, that would return negative 9. In programming, what we call variables are really quite different from what we call variables in mathematics. In mathematics, variables are used in equations such that the value of a variable possibly depends upon the value of other variables, like say in the equation x equals 2y, x represents the whole range of possible values for some given y value. A variable in programming in contrast always just has one value at any moment in time. A variable is simply a symbolic name which we give a designated value, but we call them variables because over the course of time as the program executes, we can change a variable's value. Over the course of a program, a variable's value may change, it may vary, hence the name variable. Effectively, what a variable represents in the machine is a location in memory to store a value, a location we've given a symbolic name. The jargon term for a name and source code, such as the name of a variable, is identifier. Unlike in mathematics, it's generally considered bad practice to overly use single-letter variable names in programming. Identifiers, though, must conform to a few rules. They can consist of uppercase and lowercase letters, and they can also have numerals in them. However, they cannot have spaces in them, and they cannot begin with a numeral. So these three examples are all valid identifiers, but these other three are not. The top one here in New York is not valid because you cannot have spaces in your identifiers. The second one is invalid because you cannot have symbols like the carrot sign, the dollar sign, or the asterisk. And 43 ASTF, that is not valid because while identifiers may contain numerals, they cannot begin with numerals. They must begin with a letter. The last rule to keep in mind about identifiers in Pigeon is that they are case-sensitive, meaning that the case of each letter matters. So if you have an identifier in New York where n is capitalized and y is capitalized, but the other letters are lowercase, that is a different identifier than New York with all the letters lowercase, or all letters of York in uppercase, or some other mix of uppercase and lowercase letters. So all of these identifiers here are considered by the language to be totally different identifiers. If you have a variable named New York in all lowercase, you can also have at the same time a variable named New York in all uppercase, and they would be considered totally separate variables. It turns out that most popular languages with only one or two exceptions have case-sensitive identifiers. The reason case sensitivity is the norm is that it encourages programmers to be consistent. What tends to happen when a language is not case-sensitive is that the same identifier written throughout code ends up getting written several different ways, and most people feel that's bad style. It makes the code ugly and hard to read. On the other hand, even though the language allows you to have say New York all lowercase and also New York all uppercase, it's generally a bad idea. You generally shouldn't be creating identifiers that are just like other identifiers in your code except for the lettercase, because doing so easily leads to confusion and errors.