Expressions vs. Statements: A Language Comparison

Hello! Welcome to your first lesson on programming theory.

This course is designed to build a strong theoretical foundation for understanding programming languages and paradigms, moving beyond the practical application of specific languages like Python. As you requested, we'll explore functional programming, typing systems, and other core concepts, frequently referencing John C. Mitchell's "Concepts in Programming Languages" to ground our discussions.

We begin with Module 1, "Foundations of Functional Programming." The first step in understanding the functional paradigm is to grasp its most fundamental building block. This lesson addresses the following learning outcome:

Distinguish between expressions and statements, using examples from early imperative languages (e.g., C) and functional languages (e.g., Lisp).

This distinction is crucial because it represents a primary philosophical divide between imperative languages, which are built from commands that change the state of the computer, and functional languages, which are modeled on mathematical functions that transform data. Understanding this will be the bedrock for everything that follows, including concepts like purity and referential transparency.

Let's get started.

1. The Core Distinction: Expressions vs. Statements

At a high level, the difference is simple:

• An expression is a piece of code that evaluates to a value. Think of 2 + 2, which evaluates to 4, or user.name, which evaluates to a string.
• A statement is a piece of code that performs an action or causes a side effect. Think of an assignment like x = 5, a for loop, or a print command.

To get a more formal and historically-grounded perspective, please start by reading the definitions from John C. Mitchell's course slides.

To deepen this understanding, let's look at a detailed explanation from a popular programming Q&A site.

2. The Imperative Tradition: Statement-Oriented Design

As you just read, early imperative languages like FORTRAN and ALGOL were built around statements. A program was a sequence of commands to be executed in order: do this, then do that, then change this variable. Expressions existed, but often only within statements (e.g., on the right side of an assignment).

C, which you have some familiarity with, inherits this tradition but, as noted in the Stack Overflow article, begins to blur the lines. Let's see this in practice.

In C, the line is blurred in two key ways:

1. Any expression can become a statement. You can write 5 + 10; as a line in a C program. It's a valid statement. The expression 5 + 10 is evaluated to 15, and the result is then discarded. It's a useless statement, but syntactically valid.
2. Expressions can have side effects. The most common example is the assignment operator, =. In C, x = 5 is an expression that evaluates to the value 5. Its side effect is that the variable x is now assigned that value. This allows for code like y = (x = 5);, which assigns 5 to x and then assigns the result of that expression (which is 5) to y. This is a classic feature of C-family languages that is foreign to purely functional ones.

3. The Functional Tradition: Expression-Oriented Design

Functional languages, drawing their inspiration from mathematics (specifically lambda calculus), take a different approach. As you saw in the Mitchell slides on Lisp, these languages are expression-oriented. Almost everything is an expression that returns a value.

A program is not a sequence of commands to execute, but rather a single, large expression to be evaluated (which itself is composed of many smaller expressions).

Let's see how this works in Haskell, a modern, purely functional language.

The key insight here is that even control flow structures are expressions. Consider an if/else construct.

• In a statement-oriented language like C or Python, it's a statement that directs control flow:

  // C code
  int y;
  if (x > 5) {
      y = 10; // statement
  } else {
      y = 20; // statement
  }
  

  The if block itself doesn't have a value; it contains statements that perform actions (assignment).

• In an expression-oriented language like Haskell or Lisp, if/else is an expression that evaluates to a value:

  -- Haskell code
  let y = if x > 5 then 10 else 20
  

  Here, the entire if x > 5 then 10 else 20 construct is an expression that evaluates to either 10 or 20, and that resulting value is then bound to y.

This fundamental difference has profound implications. When everything is an expression that produces a value without side effects, reasoning about code becomes much more like reasoning about mathematical equations.

4. Summary and Key Takeaways

Let's consolidate what we've covered.

Feature	Statement-Oriented (e.g., C)	Expression-Oriented (e.g., Lisp, Haskell)
Primary Unit	A statement that performs an action.	An expression that evaluates to a value.
Purpose	To issue commands and change state.	To transform data and compute values.
Control Flow	if, for, while are statements that direct execution.	if, case are expressions that evaluate to a value.
Side Effects	Common and central (e.g., assignment x=5 is a core operation).	Avoided or isolated. Assignment is a binding, not a mutable action.
return	An explicit return statement is needed to give a value back from a function.	The function body is an expression; its value is implicitly returned.

This distinction is one of the most important concepts separating the imperative and functional paradigms. Your experience with Python places you in an interesting middle ground. Python is primarily imperative and statement-oriented, but it has adopted many functional features. For example, it has list comprehensions and a ternary if operator (value_if_true if condition else value_if_false), which are both expression-oriented constructs.

---

Conclusion

In this lesson, you learned to distinguish between expressions and statements, a foundational concept in programming language theory.

• Expressions evaluate to a value.
• Statements perform an action.
• Imperative languages like C are built on a sequence of statements.
• Functional languages like Lisp and Haskell are built on the evaluation of expressions.

This shift from "doing things" to "evaluating to a value" is the essence of the functional mindset.

Preview of the Next Lesson:
In our next session, we will explore referential transparency. This is a direct and powerful consequence of the expression-oriented, side-effect-free style of programming. You'll see how it allows us to reason about code as if it were a mathematical equation, a property that is difficult to achieve in statement-oriented languages.