Paradigms & Metaprogramming

The imperative paradigm is the oldest and most direct model of computation: a program is a sequence of commands that mutate a shared, mutable state. This maps almost one-to-one onto the von Neumann architecture — a CPU with registers and a RAM — which is why almost every mainstream language in the first thirty years of computing (Fortran, C, Pascal, COBOL) was imperative.

The core abstractions are the variable (a named, mutable memory cell), the assignment statement (a command to change a variable's value), and control flow (conditionals and loops that determine which commands execute next). The execution model is simple: there is a program counter, and it advances through instructions.

Structured programming (Dijkstra, 1968) was the first great reformation of the imperative paradigm. Dijkstra's famous letter 'Go To Statement Considered Harmful' argued that unrestricted goto makes programs impossible to reason about, because the control flow has no structure. The solution was to restrict control flow to three combinators: sequence (do A then B), selection (if-then-else), and iteration (while/for loops). Böhm and Jacopini proved that these three are sufficient to express any computable function — you never need goto.

Procedural programming adds a second layer of abstraction: the procedure (or subroutine), a named, reusable block of commands with parameters. Procedures give you modularity and the ability to reason locally: if you know a procedure's pre- and post-conditions, you do not need to read its body.

The key weakness of the imperative paradigm is aliasing and shared mutable state: when two parts of a program hold references to the same object, changes in one part silently affect the other. This is the root cause of an enormous class of bugs, from race conditions in concurrent code to iterator invalidation in C++. Much of the complexity in modern software engineering (locks, immutability, ownership systems like Rust's borrow checker) is the response to this weakness.

/* C: canonical imperative style */
int sum_array(int *arr, int n) {
    int total = 0;          /* mutable state */
    for (int i = 0; i < n; i++) {  /* sequence + iteration */
        total += arr[i];    /* assignment */
    }
    return total;           /* result communicated via return */
}

The functional paradigm is grounded in lambda calculus (Church, 1936), a formal system that predates electronic computers. The key insight is that computation can be modeled entirely as the evaluation of expressions — there is no notion of state, no notion of time, and no notion of sequence. A function maps inputs to outputs, and calling a function with the same inputs always returns the same output: this is referential transparency (or the absence of side effects).

Pure functions are the atomic unit. A pure function has no observable side effects (no I/O, no mutation of shared state, no dependency on global variables). This has profound engineering consequences: pure functions are trivially testable (no setup/teardown needed), trivially parallelizable (no shared state means no data races), and easily composable (f(g(x)) always means what it looks like).

Higher-order functions are functions that take other functions as arguments or return them as results. The canonical trio is:

• map(f, xs): apply f to every element of xs, return the new list
• filter(pred, xs): return those elements of xs for which pred is true
• fold/reduce(f, init, xs): accumulate a result by repeatedly applying f

These are not just conveniences — they are the functional replacements for loops, and they carry the programmer's intent more directly ("transform every element" vs. "do this in a loop").

Immutability is the practical consequence of purity: if functions cannot mutate data, all data structures must be immutable. Functional languages achieve efficient immutable data structures via structural sharing: when you 'modify' an immutable tree, you build a new root path that shares unchanged subtrees with the original (persistent data structures, Okasaki).

Lazy evaluation (Haskell) defers the evaluation of expressions until their value is actually needed. This enables infinite data structures ([1..] in Haskell is the infinite list of positive integers) and efficient short-circuiting. It also complicates reasoning about performance.

FP languages exist on a spectrum: Haskell is purely functional (side effects are tracked in the type system via monads); ML and OCaml are functional-first but allow mutation; Clojure is Lisp with immutability as the default; Scala and F# blend FP with OOP.

-- Haskell: pure functional style
-- sum a list using fold (no mutation, no loop)
sumList :: [Int] -> Int
sumList = foldr (+) 0

-- pipeline: squares of evens, using higher-order functions
result :: [Int] -> [Int]
result xs = map (^2) (filter even xs)
-- or using function composition:
result' :: [Int] -> [Int]
result' = map (^2) . filter even

The logic paradigm, best exemplified by Prolog (Programming in Logic, Colmerauer & Roussel, 1972), takes yet another stance: a program is a set of facts and rules (a knowledge base), and computation is the process of answering queries by performing logical inference.

You do not tell the computer how to compute an answer — you describe what you know about the problem, and the runtime figures out the how. This is the purest form of declarative programming: describing the desired result rather than the procedure to reach it.

Prolog's execution model is SLD resolution: given a query, the runtime attempts to unify it with the heads of clauses in the knowledge base, then recursively tries to satisfy the body goals. Backtracking allows the runtime to try alternative clauses when one path fails. Unification is pattern matching plus variable binding: X = foo(Y, 3) simultaneously matches a structure and binds variables.

Prolog is remarkably powerful for:

• Parsing and grammars (Definite Clause Grammars are Prolog's killer app)
• Constraint satisfaction
• Expert systems and knowledge representation
• Symbolic AI and theorem proving

SQL is arguably the most widely deployed declarative language. A SQL query describes which rows you want, not how to retrieve them — the query planner decides whether to use an index scan, a hash join, a nested loop join, etc. This separation of logical query from physical execution plan is a major source of SQL's power and longevity.

Datalog is the intersection of SQL and Prolog: a logic language with no function symbols (preventing infinite terms), which makes it always terminating and efficiently evaluable. Modern systems like Datomic, Souffle (for program analysis), and differential dataflow are Datalog-inspired.

The cost of the logic paradigm is unpredictable performance: because you are not specifying the algorithm, the runtime can choose a slow strategy. Prolog programmers learn to use cuts (!) and ordering to guide the search — which partially breaks the declarative purity.

% Prolog: family database + query
parent(tom, bob).
parent(tom, liz).
parent(bob, ann).
parent(bob, pat).

% rule: X is an ancestor of Y if X is a parent of Y
% OR X is a parent of some Z who is an ancestor of Y
ancestor(X, Y) :- parent(X, Y).
ancestor(X, Y) :- parent(X, Z), ancestor(Z, Y).

% Query: ?- ancestor(tom, ann).
% Runtime performs SLD resolution + unification
% Answer: true

The contrast between 'declarative' (what) and 'imperative' (how) is real but exists on a spectrum, not as a clean binary. Every high-level language is declarative relative to a lower level. C is declarative relative to assembly. SQL is declarative relative to C. A build system DSL is declarative relative to a shell script.

The key axis is how much of the 'how' you specify. Consider sorting:

• Imperative: you write Quicksort — you specify partitioning, recursion, base cases
• High-level imperative: std::sort(begin, end) — you delegate the algorithm but specify the control flow that calls it
• Declarative: ORDER BY price DESC in SQL — you state the desired ordering; the DB chooses the algorithm

Reactive programming (RxJS, Elm, Solid.js) is a declarative paradigm for time-varying values: you declare dependencies between signals/observables, and the runtime ensures values are always consistent. This is declarative in the same sense as SQL: you describe relationships, not update procedures.

Configuration languages (YAML, HCL/Terraform, Nix) push declarativeness to the limit: you describe the desired end state (which VMs should exist, which packages should be installed), and the runtime computes the diff and applies it. This is called idempotent declarative infrastructure.

Understanding where a language sits on this spectrum helps you predict its failure modes. Highly declarative languages sacrifice control (hard to optimize, hard to express algorithms that the abstraction doesn't fit). Highly imperative languages sacrifice safety and composability (shared mutable state, order-dependent bugs).

Most real-world language design lives in the middle: Python, Java, JavaScript, Rust, and Go are imperative but include functional constructs (map, filter, closures) and OOP abstractions. The skill is knowing when to reach for which sub-language.

# Python: same computation in three styles
data = [3, 1, 4, 1, 5, 9, 2, 6]

# 1. Imperative: explicit loop, mutation
result = []
for x in data:
    if x > 3:
        result.append(x * 2)

# 2. Functional (declarative within Python):
result = [x * 2 for x in data if x > 3]
# or: list(map(lambda x: x*2, filter(lambda x: x>3, data)))

# 3. Even more declarative — SQL in SQLite:
# SELECT value * 2 FROM data WHERE value > 3
# (Python's sqlite3 module handles this entirely declaratively)

Homoiconicity (from Greek: 'same representation') is a property of a language where the primary representation of programs is also a first-class data structure in the language itself. In a homoiconic language, a running program can read, construct, and manipulate the source code of other programs using exactly the same operations it uses for ordinary data.

The canonical homoiconic language is Lisp (McCarthy, 1958). Lisp programs are made of S-expressions (symbolic expressions): either atoms (42, foo, +) or lists (operator arg1 arg2 ...). A Lisp program is itself an S-expression. This means:

(+ 1 2)  ; this is BOTH a Lisp expression that evaluates to 3
         ; AND a list with three elements: the symbol +, 1, and 2

You can create this list with '(+ 1 2) (quoting prevents evaluation), inspect it with car (first element) and cdr (rest), transform it, and then evaluate it with eval. Code and data are literally the same type.

Why does this matter?

1. Macros become natural: a macro is a function from S-expressions to S-expressions, run at compile time. You can define new control structures, new syntax, new abstractions — all in the same language, with the same tools.

2. Metaprogramming is trivial: writing a program that writes programs is not a special facility — it is just ordinary list manipulation.

3. DSLs are cheap: you can embed a domain-specific language inside Lisp just by defining macros that transform DSL syntax into Lisp.

The cost: Lisp's parenthesized syntax (sometimes called 'lots of irritating silly parentheses') is unfamiliar to most programmers. The trade-off is that the syntax is regular: it has no precedence rules, no special cases, no parsing ambiguities. The entire parser is trivial. This is the 'syntactic advantage' that Paul Graham and Eric Raymond argue gives Lisp-family languages a permanent power advantage in metaprogramming.

Modern homoiconic languages include Clojure (Lisp on the JVM), Racket (a Scheme derivative), and Elixir (which has Lisp-style macros despite a more conventional syntax). Julia is designed with metaprogramming and macro hygiene as first-class concerns.

; Clojure: demonstrating homoiconicity
; A list is both data and code
(def my-code '(+ 1 2 3))   ; quoted: not evaluated, just a list
(println (type my-code))    ; clojure.lang.PersistentList
(println (first my-code))   ; +   (a symbol)
(println (rest my-code))    ; (1 2 3)

; eval treats the list as code
(println (eval my-code))    ; 6

; build code programmatically and run it
(def dynamic-sum
  (list '+ 10 20 30))       ; constructs (+ 10 20 30)
(println (eval dynamic-sum)); 60

A macro is a compile-time transformation: it takes a piece of syntax (an AST node or S-expression) as input and returns a new piece of syntax as output, which is then compiled in place of the original. This happens before evaluation — unlike a function, a macro's arguments are not evaluated before being passed to it.

This 'evaluation before/after' distinction is crucial. Consider defining my-and (short-circuit AND) in Lisp:

; This CANNOT be a function: functions evaluate all args first
(defn bad-and [a b] (if a b false))   ; evaluates b even if a is false

; This CAN be a macro: transforms syntax at compile time
(defmacro my-and [a b]
  `(if ~a ~b false))  ; backtick=quasiquote, tilde=unquote
; Expands (my-and (expensive) (also-expensive))
; into:  (if (expensive) (also-expensive) false)
; Now (also-expensive) is only evaluated if (expensive) is truthy

Macro hygiene is the critical engineering concern: naive macros can accidentally capture variable names from the surrounding scope. Hygienic macros (introduced in Scheme) rename generated symbols to avoid capture. Clojure enforces hygiene via gensym in macros; Racket's syntax-rules and syntax-parse provide a full hygiene system.

Macros in Lisp/Clojure vs. macros in C/C++ (#define) are fundamentally different:

• C macros are textual substitution (lexer-level, no understanding of structure)
• Lisp macros are syntactic/AST transformation (they operate on parsed structure)

C macros are notoriously error-prone (#define SQUARE(x) x*x breaks for SQUARE(1+2)). Lisp macros do not have this problem because they operate on trees, not text.

Template metaprogramming in C++ is a kind of (accidental, Turing-complete) macro system at the type level, discovered in the 1990s. C++11 constexpr and C++20 concepts are more controlled compile-time computation facilities.

Rust's procedural macros are the modern industrial synthesis: macros that take token streams and return token streams, with access to the full Rust language for transformation logic. Rust's #[derive(Debug)], println!, vec!, and async/await are all macros. The entire async/await machinery is syntax sugar that desugars into state machines via macros.

; Clojure: writing a real macro (swap! idiom)
; Goal: (with-logging expr) should:
;   1. Print "Evaluating: <source of expr>"
;   2. Evaluate expr
;   3. Print the result
;   4. Return the result

(defmacro with-logging [expr]
  `(let [result# ~expr]   ; result# is a gensym (hygienic)
     (println "Evaluated:" '~expr "=>" result#)
     result#))

; Usage:
(with-logging (+ 1 2 3))
; Prints: Evaluated: (+ 1 2 3) => 6
; Returns: 6

; A function CANNOT do this: it cannot access '(+ 1 2 3)
; as source code — it only sees the evaluated value 6

Reflection (also called introspection) is the ability of a program to examine and modify its own structure and behavior at runtime. Unlike macros (which operate at compile time), reflection operates while the program is executing.

Reflection capabilities exist on a spectrum:

1. Type introspection: asking 'what type is this object?' at runtime (isinstance() in Python, instanceof in Java, typeof in JavaScript)
2. Structural reflection: enumerating the fields, methods, and attributes of an object at runtime
3. Behavioral reflection: modifying the behavior of methods at runtime (monkey-patching)
4. Metaobject protocol (MOP): a reflective API that exposes the object system itself as objects that can be modified (CLOS in Common Lisp is the canonical example)

Python's reflection is rich and widely used:

• dir(obj): list all attributes and methods
• getattr(obj, name): get attribute by string name
• setattr(obj, name, value): set attribute by string name
• inspect module: get source code, signatures, call stack
• __class__, __dict__, __bases__: metaclass machinery

Java's java.lang.reflect package is the industrial-strength version: you can instantiate classes, invoke methods, and access fields entirely by name, at runtime. This powers Spring's dependency injection, JUnit's test discovery, and virtually every Java framework.

The cost of reflection is performance (no static dispatch, no dead-code elimination) and safety (bypasses the type system; errors become runtime exceptions instead of compile errors). Reflective code is also harder to analyze with IDEs and harder to understand for human readers.

Metaclasses in Python take reflection to the extreme: a metaclass is the class of a class. When Python creates a class, it calls the metaclass's __new__ and __init__. By defining a custom metaclass, you can intercept class creation and modify the class. This is used by Django's ORM (to turn class attributes into database column definitions), Flask-SQLAlchemy, and protocol buffer code generators.

The distinction between reflective languages (Python, Ruby, JavaScript, Smalltalk) and non-reflective languages (C, early Haskell) is largely a spectrum defined by how much runtime type information (RTTI) survives compilation. Rust preserves essentially none (by design, for performance and safety); Python preserves almost everything.

# Python: reflection in practice
class MyClass:
    x = 10
    def greet(self): return "hello"

obj = MyClass()

# Type introspection
print(type(obj))            # <class '__main__.MyClass'>
print(isinstance(obj, MyClass))  # True

# Structural reflection
print(dir(obj))             # lists all attributes/methods
print(vars(obj))            # instance __dict__

# Dynamic dispatch by name
method_name = "greet"
result = getattr(obj, method_name)()
print(result)               # "hello"

# Metaclass: intercept class creation
class TrackingMeta(type):
    def __new__(mcs, name, bases, namespace):
        print(f"Creating class: {name}")
        return super().__new__(mcs, name, bases, namespace)

class Tracked(metaclass=TrackingMeta):
    pass
# Prints: Creating class: Tracked

A domain-specific language (DSL) is a programming language or notation tailored to a particular problem domain. The contrast is with general-purpose languages (GPLs) which are designed to solve any computable problem.

DSLs come in two flavors:

External DSLs have their own parser and runtime, completely separate from the host language. Examples: SQL, CSS, regular expressions, Makefiles, HCL (Terraform), LaTeX, Verilog. External DSLs provide maximum syntactic freedom but require building (or using) a full language implementation.

Internal (embedded) DSLs are built within a host language, using the host language's syntax and metaprogramming facilities to create a domain-specific feel. Examples: jQuery (fluent API for DOM manipulation), RSpec (Ruby testing DSL), Rails routes (get '/users/:id', to: 'users#show'), Haskell's parser combinators (Parsec), React's JSX (technically a macro expansion).

The case for DSLs is expressiveness: code in a well-designed DSL reads like a specification of the problem, not a description of the solution procedure. A SQL query reads like an English question. A CSS rule reads like a design spec. This makes the code easier to write, read, audit, and reason about for domain experts who are not programmers.

The Greenspun corollary: every sufficiently complex GPL program eventually re-invents a mini-language (a config file format, a query syntax, a scripting interface). The choice is between doing this deliberately and well, or accidentally and badly.

DSL design principles:

1. Principle of least surprise: DSL constructs should do what a domain expert would expect
2. Composability: small constructs should combine to express complex ideas
3. Good error messages: DSL errors should be expressed in domain terms, not host-language stack traces
4. Leaky abstractions: every DSL eventually exposes the host language underneath — design the escape hatch carefully

Fluent interfaces (method chaining) are the simplest form of internal DSL in object-oriented languages. The builder pattern is a common implementation:

query = (QueryBuilder()
  .from_table('orders')
  .where(status='shipped')
  .order_by('date', desc=True)
  .limit(10)
  .build())

This reads like a query specification, not a program.

# Python: a minimal internal DSL for HTML generation
# Demonstrates DSL-style API design

class Tag:
    def __init__(self, name):
        self.name = name
        self.children = []
        self.attrs = {}

    def __call__(self, *children, **attrs):
        t = Tag(self.name)
        t.children = list(children)
        t.attrs = attrs
        return t

    def __str__(self):
        attr_str = ' '.join(f'{k}="{v}"' for k, v in self.attrs.items())
        open_tag = f'<{self.name} {attr_str}>' if attr_str else f'<{self.name}>'
        body = ''.join(str(c) for c in self.children)
        return f'{open_tag}{body}</{self.name}>'

div, p, span = Tag('div'), Tag('p'), Tag('span')

# Usage reads like HTML structure:
page = div(
    p(span('Hello, ', id='greeting'), 'world!'),
    class_='container'
)
print(page)
# <div class_="container"><p><span id="greeting">Hello, </span>world!</p></div>

Language-oriented programming (LOP) is the programming methodology that takes DSLs as the primary unit of abstraction. Instead of decomposing a large problem into functions and objects, you decompose it into a tower of languages: each layer is a small DSL that is well-suited to its stratum of the problem, implemented in terms of the layer below.

The idea was articulated by Ward Cunningham and Kent Beck, but its deepest expression is in Racket (formerly PLT Scheme), which was explicitly designed as a 'programming language programming language'. Racket's #lang directive lets a single file use a completely different language front-end while sharing the Racket runtime. #lang racket is just the default; #lang typed/racket, #lang scribble/manual (for documentation), #lang rosette (for solver-aided programming), and #lang web-server are all real Racket languages.

The LOP workflow is:

1. Understand the problem domain deeply
2. Design the ideal notation for that domain
3. Implement that notation as a language layer (macros, DSL, or full language) atop a suitable host
4. Write the actual application in that notation

This is how Emacs Lisp powers Emacs (the editor is a Lisp interpreter; every feature is a Lisp program). It is how TeX/LaTeX works (TeX is a macro system; LaTeX is a DSL for document typesetting built on TeX). It is how React works: JSX is a notation for UI trees that macro-expands to React.createElement(...) calls.

Stratified language towers are found in the world's most sophisticated software:

• GHC Haskell: Template Haskell (compile-time metaprogramming) → type-class system → core language
• Racket: #lang front-ends → macro system → runtime
• Emacs: Emacs Lisp → editor primitives → C core
• LaTeX: user macros → LaTeX macros → TeX primitives

The philosophical claim of LOP is that the right abstraction is often a language, not a library. A library gives you new functions; a language gives you new syntax, new evaluation rules, new error messages, new static analysis. When the domain is rich enough, this extra investment pays enormous dividends.

; Racket: #lang directive for language-oriented programming
; File: myapp.rkt
#lang racket   ; this file uses the Racket language

; File: my-html.rkt
#lang scribble/html  ; this file IS an HTML document, Racket-extended
; (scribble/html is a real Racket language for generating HTML)

; Defining a tiny language via macros:
; A 'state machine' DSL in Racket
(define-syntax-rule
  (define-machine name [state -> next-state : action] ...)
  (define (name current-state input)
    (match (list current-state input)
      [(list 'state input) (action) 'next-state] ...
      [_ (error "no transition")])))

; Now the application reads like a state-machine spec:
; (define-machine traffic-light
;   [red   -> green  : show-green ]
;   [green -> yellow : show-yellow]
;   [yellow-> red    : show-red  ])

Object-oriented programming (OOP) is not a single idea but a cluster of related ideas: encapsulation (bundling data and the operations on it), inheritance (reusing and specializing behavior), polymorphism (the same interface, different implementations), and message passing (Alan Kay's original vision: objects communicate by sending messages to each other, each object deciding how to respond).

It is important to understand that OOP is distinct from the imperative paradigm, though most OOP languages (Java, C++, Python) are imperative-OOP hybrids. Smalltalk is the purest expression of Kay's vision: everything is an object, including integers and classes, and all computation is message passing. Java is a more rigid, class-centric version. Python is flexible enough to blend OOP and FP freely.

Subtype polymorphism (runtime dispatch) is OOP's killer feature: you write code against an interface, and the correct implementation is chosen at runtime based on the actual type of the object. This enables the Open/Closed Principle: code is open for extension (add new subclasses) but closed for modification (don't change existing code).

The expression problem (Wadler, 1998) is a fundamental tension in OOP: it is easy to add new types (subclass) but hard to add new operations (without modifying all existing classes). Functional programming has the dual problem: easy to add new operations (new functions), hard to add new types (must update all pattern matches). This is not a bug in either paradigm — it is a fundamental trade-off in extensibility.

Prototype-based OOP (JavaScript, Lua, Self) replaces classes with prototypes: objects inherit directly from other objects, not from classes. This is more flexible but less structured. JavaScript's class syntax is syntactic sugar over its prototype chain.

The criticism of OOP: in large codebases, deep inheritance hierarchies become brittle and hard to reason about ('the gorilla/banana problem': you wanted a banana, you got a gorilla holding the banana and the entire jungle). Modern OOP best practice favors composition over inheritance and interface-based programming (program to an interface, not an implementation).

# Python: OOP with polymorphism + composition
from abc import ABC, abstractmethod

class Shape(ABC):
    @abstractmethod
    def area(self) -> float: ...
    def describe(self):
        print(f"{type(self).__name__} area: {self.area():.2f}")

class Circle(Shape):
    def __init__(self, r): self.r = r
    def area(self): return 3.14159 * self.r ** 2

class Rectangle(Shape):
    def __init__(self, w, h): self.w, self.h = w, h
    def area(self): return self.w * self.h

shapes = [Circle(3), Rectangle(4, 5), Circle(1)]
for s in shapes:
    s.describe()   # polymorphic dispatch: each calls its own area()
# Circle area: 28.27 / Rectangle area: 20.00 / Circle area: 3.14

Orthogonal to the imperative/functional/logic axis is the type system axis, which profoundly shapes how a language feels and what errors it can prevent.

A type system is a tractable syntactic method for proving the absence of certain program behaviors (Pierce). The key properties:

• Static vs. dynamic: types checked at compile time (Java, Haskell, Rust, C++) vs. at runtime (Python, JavaScript, Ruby). Static typing catches errors earlier and enables compiler optimizations; dynamic typing enables more flexibility and faster prototyping.

• Strong vs. weak: whether the language prevents (strong: Python, Haskell) or allows (weak: C, JavaScript) implicit coercions between incompatible types. 1 + '1' is a runtime error in Python, '11' in JavaScript, undefined behavior in C.

• Nominal vs. structural: does a type match based on its name/declaration (Java: you must explicitly implements Iterable) or based on its structure (TypeScript, Go: if it has the right methods, it is compatible — 'duck typing' with static checking)?

• Dependent types (Idris, Coq, Agda, Lean): types can depend on values. Vector n a is the type of lists of length exactly n. This allows the type system to prove mathematical theorems and catch errors that are impossible to express in simpler type systems. Dependent types blur the line between programs and proofs (the Curry-Howard correspondence).

The Hindley-Milner type system (used in Haskell, OCaml, ML) achieves a remarkable balance: full type inference (you rarely need to write type annotations) combined with parametric polymorphism (generics) and soundness (a well-typed program never has a type error at runtime). This is one of the great achievements of programming language theory.

Gradual typing (Siek & Taha, 2006) allows mixing typed and untyped code in the same program: Python's type hints, TypeScript, Typed Racket. This is pragmatically valuable for migrating large dynamic codebases toward safety incrementally.

-- Haskell: Hindley-Milner type inference + parametric polymorphism
-- No type annotations needed — the compiler infers everything
myLength xs = case xs of
    []     -> 0
    (_:rest) -> 1 + myLength rest
-- Inferred type: myLength :: [a] -> Int
-- Works for ANY list element type 'a'

-- Dependent-type flavor (pseudocode for Vec)
-- safeHead :: Vec (S n) a -> a   -- type-level proof: list is non-empty
-- can ONLY be called on non-empty lists; empty list is a compile error

-- TypeScript: structural typing
interface HasName { name: string }
function greet(x: HasName): string { return `Hi, ${x.name}` }
// Works for ANY object with a name field — no explicit 'implements'