In this unit, we’re going to be covering what programs mean and especially what they mean in terms of their context, the environment in which they operate. This is called formal symantics, and while it may initially seem a bit dry, it’s actually one of my favorite topics in computer science. In fact, before my research moved on to the greater glory of fixing bugs in programs, I started out trying to find bugs in programs, and one of the surprising lessons in finding bugs in programs is that both the program and our idea of what it should mean matter. All of you have probably had a bug in your code at some point or another, and officially a bug is really just an instance where the program’s meaning is different from its specification. What it does do and what it should do don’t agree. A, perhaps, surprising result is that in industrial practice a lot of the time the mistake is actually with the specification, and you’ve probably seen this in real life. A friend might’ve asked you to do something. You go and do it faithfully only to discover that that wasn’t actually what the friend wanted to have happen. It’s just what they told you to do. The same sort of thing comes up in bug finding and bug fixing research. Often the formal specification for a problem, this would never happen for the homework problems here, is vague or imprecise. Not enough to tell you exactly what’s supposed to happen. Regardless of whether the problem is with the source code or the specification, understanding what code means in context is critical to figuring out if it’s right or wrong, and that’s what we’re going to do in this unit.