What Is a Statement?

Introduction

Around 350 BCE, Aristotle drew a line that every programmer crosses every day without knowing it.

He was not writing about computers. He was writing about argumentation — how to distinguish valid reasoning from sophistry. But in doing so, he identified the atomic unit of all logical thought: a declarative sentence that is either true or false, never both, never neither.

He called it a proposition. We now call it a boolean.

Every if statement ever written — in C, Python, SQL, assembly — bottoms out at this idea. Before you can understand state machines, distributed consensus, or database transaction models, you have to understand what it means for a sentence to have a truth value. That is where this chapter begins.

Thread Activation

Thread 7 (State Machines) originates here.

A statement is the smallest possible unit of logical state. It can be True or False. Nothing else. This binary quality is not a limitation — it is a foundation. Every state machine you will encounter in this series, from a traffic light controller to a distributed database’s leader election protocol, is built from statements about the world that are either satisfied or not.

This is the mathematical root of a pattern that will appear at every level of the computing stack. By the time you finish this series, you will have seen it as a state machine, a database transaction model, and an architectural principle. Right now, it is just a sentence. Keep that in mind.

The Concept

A statement (also called a proposition) is a declarative sentence with a definite truth value: it is either True or False.

Three examples of statements:

• “The integer 7 is prime.” — True.
• “Python lists are zero-indexed.” — True.
• “Every HTTP request returns within 100ms.” — False (in general).

Three examples of non-statements:

• “Is the server running?” — A question. No truth value.
• “Restart the service.” — A command. No truth value.
• “x is greater than 5.” — An open statement. Truth value unknown until x is assigned.

The distinction matters. Logic, and therefore programming, operates only on things that can be evaluated. Questions and commands cannot be evaluated as true or false. Open statements defer evaluation until a value is substituted.

x > 10

How It Works

# These are statements — each evaluates to True or False
is_connected = server_status == "running"   # statement: server_status equals "running"
has_capacity = queue_depth < MAX_QUEUE      # statement: queue_depth is less than MAX_QUEUE
is_valid_request = content_length > 0       # statement: content_length is positive

# This is a conditional — it branches on the truth value of a statement
if is_connected and has_capacity:
    process_request()

def can_process(request_size: int, queue_depth: int, max_queue: int) -> bool:
    # Statement: the queue has room for this request
    queue_has_room = queue_depth < max_queue

    # Statement: the request is within the size limit
    request_is_valid = request_size > 0 and request_size <= MAX_REQUEST_SIZE

    # Compound statement: both conditions hold
    return queue_has_room and request_is_valid

Tradeoffs

AT3 — Simplicity vs. Flexibility

Classical logic uses exactly two truth values. This is maximally simple. It enables efficient hardware implementation — a single bit. It enables exhaustive testing — there are exactly two cases. It enables formal verification — proofs reduce to symbolic manipulation of True and False.

The cost is expressiveness. Real systems have states that do not reduce cleanly to binary. “Is this service healthy?” might be “yes”, “no”, “degraded”, “unknown”, or “recovering.” Forcing this into a binary produces false precision.

The engineering resolution is not to abandon binary logic but to be explicit about the mapping. Define a ServiceStatus enum. Write a function is_healthy(status: ServiceStatus) -> bool. The boolean interface preserves the simplicity guarantee. The enum preserves the expressiveness. The explicit mapping makes the tradeoff visible.

from enum import Enum

class ServiceStatus(Enum):
    HEALTHY = "healthy"
    DEGRADED = "degraded"
    UNHEALTHY = "unhealthy"
    UNKNOWN = "unknown"

def is_healthy(status: ServiceStatus) -> bool:
    # Explicit mapping from multi-valued state to binary statement
    # This is a design decision: DEGRADED maps to True here
    # A different caller might map DEGRADED to False
    return status in (ServiceStatus.HEALTHY, ServiceStatus.DEGRADED)

This is AT3 in practice: the boolean interface is simple; the enum is flexible; the mapping function is the explicit tradeoff point.

Where It Fails

FM8 — Schema/Contract Violation

A statement is a contract between the writer and the evaluator. The writer claims: “this expression will resolve to True or False.” The evaluator trusts that claim. When the claim is wrong, the contract is violated.

Three ways this happens in practice:

1. Type coercion masks non-boolean values.

Python treats many non-boolean values as truthy or falsy. This is convenient and dangerous.

# Apparent statement: "the response has a body"
if response.body:
    process(response.body)

If response.body is an empty list, this is False — correct. If response.body is 0, this is False — possibly incorrect if 0 is a valid body. If response.body is None, this is False — correct. The problem: the code does not distinguish between “body is empty” and “body is absent.” They are different facts. The statement conflates them.

2. Stale truth values.

# Evaluated once, held forever
cache_is_warm = precheck_cache()

# ... 500 milliseconds of network calls later ...

if cache_is_warm:           # was true 500ms ago; may now be false
    read_from_cache()       # cache could have been evicted

The statement was True when evaluated. The fact changed. The stored truth value did not. This is not a logic error. It is a temporal contract violation. The statement implicitly claims “the cache is warm right now.” Storing the result breaks that claim.

3. Ambiguous natural language statements mapped to code.

“The user is authorized” — authorized to do what? At what privilege level? From which IP range? In which context?

A natural language statement that sounds definite often has hidden parameters. When mapped to a boolean, those parameters become invisible. The code evaluates the statement for one specific interpretation. Callers assume their interpretation. The contract is violated silently.

# Bad: "is_authorized" — authorized for what?
def is_authorized(user: User) -> bool:
    return user.role == "admin"

# Better: explicit about what the statement means
def is_authorized_for_deletion(user: User, resource: Resource) -> bool:
    return user.role == "admin" and resource.owner_id == user.id

The second version is a statement with explicit parameters. Its contract is clear.

Real Systems

Authorization systems are built from statements. AWS IAM policies are logical expressions over statements like “this principal has this action on this resource.” When a policy evaluates to True, access is granted. The entire access control model is statement evaluation.

Health checks in Kubernetes are statements. livenessProbe evaluates: “is this container alive?” The probe returns a binary result. Kubernetes branches on it. The complexity is in defining what “alive” means precisely enough that the statement evaluates correctly.

Database constraints are statements about data. NOT NULL, UNIQUE, CHECK (age > 0) — each is a statement that must hold True for every row. The database evaluates these statements at write time. A constraint violation is a statement that evaluated to False when it was required to be True. This is FM8: a schema/contract violation.

Compiler type systems evaluate statements about programs before the programs run. “This variable is always an integer” is a statement. The type checker proves it True or False at compile time. A type error is a statement the type checker cannot prove True — a contract violation caught early.

Exercises

def should_retry(attempt: int, error_code: int, is_idempotent: bool) -> bool:
    return attempt < 3 and error_code >= 500 and is_idempotent