Functional Programming Concepts

Why This Matters

Functional programming isn't just an academic exercise—it's the foundation for writing code that's easier to test, debug, and parallelize. You're being tested on your ability to recognize how these concepts work together: why pure functions enable referential transparency, how immutability prevents bugs in concurrent systems, and when lazy evaluation actually improves performance. These ideas show up everywhere from React's state management to distributed systems design.

Don't just memorize definitions—understand the underlying principles each concept demonstrates. Exam questions will ask you to identify which technique solves a specific problem, compare trade-offs between approaches, and write code that applies these patterns correctly. Master the why behind each concept, and you'll handle any FRQ they throw at you.

---

Purity and Predictability

These concepts form the bedrock of functional programming by ensuring your code behaves consistently. When functions have no hidden dependencies or effects, reasoning about program behavior becomes straightforward.

Pure Functions

• Same input always produces same output—this deterministic behavior makes functions predictable and testable without complex setup
• No side effects means the function doesn't modify external state, access I/O, or depend on mutable data outside its parameters
• Enables parallelization because pure functions can run on any thread without race conditions or synchronization concerns

Referential Transparency

• Expressions can be replaced with their values—if $f(3) = 9$, you can substitute $9$ anywhere $f(3)$ appears without changing behavior
• Requires purity since any side effects would make substitution change program meaning
• Compiler optimization becomes possible through techniques like memoization and common subexpression elimination

---

State Management Without Mutation

Functional programming handles state differently than imperative code. Instead of modifying existing data, you create new versions—making state changes explicit and trackable.

Immutability

• Data never changes after creation—instead of modifying objects, you create new ones with the desired changes
• Eliminates shared mutable state bugs that cause race conditions, making concurrent programming dramatically safer
• Persistent data structures share unchanged portions between versions, so immutability doesn't mean copying everything

Closures

• Functions capture their lexical environment—variables from outer scopes remain accessible even after that scope exits
• Enables private state without classes by returning functions that reference enclosed variables
• Essential for callbacks and event handlers where you need to "remember" context from when the function was defined

---

Functions as Building Blocks

Treating functions as data unlocks powerful abstraction patterns. When functions can be passed around like any other value, you can build complex behavior from simple, composable pieces.

First-Class Functions

• Functions are values—assign them to variables, store them in data structures, pass them as arguments, return them from other functions
• Enables callback patterns where behavior is parameterized by passing different functions to the same higher-order function
• Foundation for all other techniques in this section; without first-class functions, higher-order functions and composition aren't possible

Higher-Order Functions

• Take functions as arguments or return functions as results—map, filter, and reduce are canonical examples
• Abstract common patterns so you write the iteration logic once and parameterize the operation
• Replace loops with declarations—instead of how to iterate, you specify what transformation to apply

Function Composition

• Combine simple functions into complex pipelines—if $f: A \rightarrow B$ and $g: B \rightarrow C$, then $g \circ f: A \rightarrow C$
• Data flows through transformations making the processing pipeline explicit and readable
• Modularity through decomposition—break complex operations into testable single-purpose functions, then compose them

---

Flexible Function Application

These techniques give you fine-grained control over how and when functions receive their arguments. By transforming function signatures, you create more reusable and expressive code.

Currying and Partial Application

• Currying transforms $f(a, b, c)$ into $f(a)(b)(c)$—a chain of single-argument functions
• Partial application fixes some arguments early, returning a function that takes the remaining ones—useful for creating specialized versions of general functions
• Not the same thing—currying always produces unary functions; partial application can fix any number of arguments at once

Recursion

• Functions call themselves to break problems into smaller identical subproblems until reaching a base case
• Natural fit for recursive data structures—trees, linked lists, and nested structures often have elegant recursive solutions
• Tail call optimization (when supported) allows recursive functions to run in constant stack space by reusing the current frame

---

Evaluation Strategy

When your code runs matters as much as what it computes. Lazy evaluation defers computation until results are actually needed, enabling patterns impossible with eager evaluation.

Lazy Evaluation

• Computation delayed until value is needed—expressions aren't evaluated when bound, only when consumed
• Infinite data structures become possible—generate elements on demand without computing the entire (infinite) sequence
• Avoids unnecessary work when only part of a result is used, but can make performance harder to predict and debugging trickier

---

Quick Reference Table

---

Self-Check Questions

1. Which two concepts together guarantee that an expression can be safely replaced with its computed value throughout a program?

2. You need to create a specialized logging function from a general one by pre-filling the log level. Would you use currying or partial application? Explain the difference.

3. Compare and contrast how immutability and closures each handle state. In what scenario would you prefer one over the other?

4. A function reads from a database and returns user data. Is this function pure? What property does it violate, and what are the testing implications?

5. FRQ-style: Given a list processing task that may not need all results, explain how lazy evaluation combined with higher-order functions like map and filter could improve performance compared to eager evaluation.