Recursion and Recursive Thinking

Last Updated May 30, 2026

Recursion is one of the deepest ideas in mathematics, computation, logic, language, and systems thinking. A structure is recursive when it is defined in terms of smaller instances of itself. A process is recursive when it solves a problem by reducing it to simpler versions of the same problem. A pattern is recursive when each stage depends on previous stages. A proof is recursive when it establishes a base case and then shows how truth propagates from one case to the next.

Recursive thinking appears whenever a whole is built from parts that resemble the whole: sequences, trees, fractals, algorithms, proof by induction, grammar, syntax, nested definitions, self-similar forms, dynamic programming, divide-and-conquer methods, formal languages, data structures, feedback processes, and mathematical models of growth. It is one of the central bridges between mathematical abstraction and computational procedure.

This article examines recursion and recursive thinking as a mode of mathematical reasoning. It explores recursive definitions, base cases, recurrence relations, mathematical induction, trees, self-similarity, divide-and-conquer algorithms, dynamic programming, formal grammar, Haskell-style algebraic data types, SQL metadata schemas, recursive modeling, and the responsible interpretation of recursive systems in computation, artificial intelligence, education, institutions, and public decision-making.

What Recursion Means

Recursion means defining, constructing, or solving something in terms of smaller or simpler versions of itself. A recursive definition contains at least two essential parts: a base case that does not refer back to itself, and a recursive rule that reduces a larger case to smaller cases. Without a base case, the process never stops. Without a recursive rule, there is no self-referential structure.

A familiar example is the factorial function. The factorial of \(n\), written \(n!\), is the product of all positive integers from \(1\) to \(n\). It can be defined recursively: \(0!=1\), and for \(n\geq1\), \(n!=n(n-1)!\). The larger case depends on a smaller case until the base case is reached.

Recursion is not only a programming technique. It is a way of understanding structure. A sequence may be recursive if each term depends on earlier terms. A tree is recursive because each branch may contain smaller trees. A proof by induction is recursive because the truth of a statement at one level supports truth at the next. A grammar is recursive when phrases can contain smaller phrases of the same type.

Recursive thinking therefore asks: What is the simplest case? How does a larger case reduce to smaller cases? What rule connects the levels? What guarantees that the process stops, stabilizes, or remains meaningful?

Back to top ↑

Recursive Thinking as a Mathematical Habit

Recursive thinking is the habit of understanding a problem by identifying its internal repetition. Instead of solving the whole problem directly, recursive thinking asks whether the problem contains smaller versions of itself. If it does, the larger problem may be solved by solving smaller problems and combining their results.

This is a profound shift in mathematical attention. A non-recursive solution may look for a direct formula. A recursive solution looks for a structural reduction. It asks: if I already knew how to solve the smaller case, how would I solve the larger case? That question appears in induction proofs, recurrence relations, divide-and-conquer algorithms, dynamic programming, tree traversal, parsing, and formal definitions.

Recursive thought is not always about numbers. It can apply to structure. To understand a directory, inspect its files and recursively inspect its subdirectories. To understand a proof tree, examine its conclusion and recursively examine the lemmas that support it. To understand a sentence, parse the phrase and recursively parse the phrases inside it. To understand a system, identify subsystems that contain similar patterns of relation and behavior.

Recursive thinking is powerful because it turns complexity into layered repetition. It reveals that large structures can often be understood through simple rules applied repeatedly.

Back to top ↑

Base Cases, Recursive Steps, and Stopping Conditions

Every sound recursive process needs a base case. The base case is the simplest case that can be answered directly. It prevents infinite regress. A recursive rule then reduces every larger case toward the base case. A stopping condition ensures that recursive calls do not continue forever.

In mathematics, the base case establishes where a definition begins. In programming, it prevents a function from calling itself indefinitely. In proof, it anchors induction. In tree structures, leaves terminate branches. In grammar, terminal symbols stop phrase expansion. In systems modeling, boundary conditions can function like base cases by specifying where recursive dependency stops.

Recursive failure often comes from one of three errors: missing base case, incorrect base case, or recursive rule that does not move toward the base case. These errors can produce infinite loops, invalid proofs, incorrect recurrence values, or poorly specified models.

Base cases are not merely technical details. They are foundational commitments. They define where a system begins, how a process becomes meaningful, and how a chain of reasoning avoids circularity.

Back to top ↑

Recursive Sequences and Recurrence Relations

A recurrence relation defines a sequence by relating each term to previous terms. Instead of giving a closed formula for \(a_n\), a recurrence tells how to generate \(a_n\) from earlier values. This makes recurrence one of the clearest mathematical forms of recursion.

The Fibonacci sequence is the classic example. It begins with \(F_0=0\) and \(F_1=1\). Every later term is the sum of the previous two terms.

Recurrence relations appear in combinatorics, algorithms, population models, finance, probability, dynamic systems, computer science, and mathematical biology. They are especially natural when a process evolves step by step or when a structure of size \(n\) can be built from structures of smaller sizes.

Recurrence relations teach that formulas are not the only way to know a sequence. Sometimes the most natural description of a structure is generative: start here, repeat this rule, and the pattern unfolds.

Back to top ↑

Recursion and Mathematical Induction

Mathematical induction is the proof method most closely associated with recursion. It proves statements indexed by natural numbers by establishing a base case and then proving an inductive step. The inductive step shows that if the statement holds for one case, it holds for the next. This mirrors recursive definition: base case plus rule.

Induction and recursion are two sides of the same structural idea. Recursion defines or computes by moving downward toward the base case. Induction proves by moving upward from the base case. In both cases, the structure of the natural numbers provides the ladder.

Strong induction extends this idea. Instead of assuming only \(P(n)\) to prove \(P(n+1)\), it assumes all previous cases \(P(0),P(1),\ldots,P(n)\). This is useful when a structure can break into several smaller pieces, not only the immediately preceding one.

Recursive definitions often require inductive proofs. If a function, tree, grammar, or algorithm is defined recursively, the most natural way to prove something about it is often to prove it recursively as well.

Back to top ↑

Trees, Nested Structure, and Recursive Objects

Trees are among the clearest examples of recursive objects. A tree may be a leaf, or it may be a node connected to smaller trees. This means the same definition applies at every level: a whole tree is built from subtrees, and each subtree is itself a tree.

Tree structures appear in mathematical expressions, proof dependencies, syntax trees, file systems, taxonomies, decision trees, search trees, organizational hierarchies, genealogies, game trees, classification systems, and knowledge architectures. Recursive thinking is essential for navigating and analyzing them.

Many operations on trees are recursive. To count nodes, count the root and then recursively count nodes in each subtree. To compute tree depth, compute the depth of each subtree and add one. To evaluate an expression tree, evaluate its subexpressions and combine their values according to the root operator.

Trees show why recursion is not only temporal. Recursion can also be spatial, logical, and structural. The same form repeats inside itself.

Back to top ↑

Self-Similarity, Fractals, and Recursive Form

Self-similarity occurs when a structure resembles itself at different scales. Fractals are mathematical objects that often display recursive or iterative self-similarity. A simple rule is applied repeatedly, producing increasingly detailed structure. The result may appear complex, but it grows from repetition of a simple transformation.

The Cantor set, Sierpiński triangle, Koch curve, and many branching forms are classical examples of recursive construction. Begin with an initial shape. Apply a rule to produce a new shape. Apply the same rule again to each part. Continue indefinitely or approximate through finite iterations.

Fractals are important because they show how recursion can generate complexity without requiring complicated rules. Branching trees, coastlines, river networks, vascular systems, roots, lightning, and other natural forms may exhibit approximate recursive or self-similar patterns, though mathematical fractals should not be confused with physical systems in a simplistic way.

Recursive form teaches that repeated rules can produce structures far richer than the rule itself appears to contain. This is one of the reasons recursion is central to mathematical imagination.

Back to top ↑

Recursive Algorithms and Divide-and-Conquer Reasoning

Recursive algorithms solve a problem by breaking it into smaller problems of the same kind. The algorithm then solves the smaller problems recursively and combines the results. This strategy is called divide-and-conquer when the problem is split into subproblems that can be solved independently.

Merge sort is a classic example. To sort a list, divide it into two halves, recursively sort each half, and merge the sorted halves. Binary search works recursively by comparing the target to the middle element and then searching the relevant half. Recursive tree traversal visits a node and then recursively visits its children.

Recursive algorithms require both correctness and termination. Correctness asks whether the recursive solution actually solves the original problem. Termination asks whether the recursive calls eventually reach base cases. Efficiency asks whether repeated recursive calls create unnecessary work.

Recursive algorithms show how mathematical structure becomes executable procedure. A recursive idea becomes a program when its base cases, recursive cases, and combination rules are made explicit.

Back to top ↑

Dynamic Programming and Memoized Recursion

Naive recursion can be inefficient when the same subproblem is solved repeatedly. Dynamic programming improves recursive computation by storing subproblem results and reusing them. Memoization stores results in a cache during top-down recursion. Tabulation builds results bottom-up in a table.

The Fibonacci sequence illustrates the issue. A naive recursive Fibonacci function recomputes the same values many times. Memoization stores each computed value so later calls can reuse it. The mathematical recurrence remains the same, but the computational strategy changes dramatically.

Dynamic programming applies when a problem has overlapping subproblems and optimal substructure. Overlapping subproblems mean the same smaller problems appear repeatedly. Optimal substructure means a solution can be built from solutions to smaller problems.

Dynamic programming shows that recursive thinking is not opposed to efficiency. It becomes efficient when repeated structure is identified, named, stored, and reused.

Back to top ↑

Recursive Grammar, Language, and Formal Systems

Language is deeply recursive. A sentence may contain a phrase, which may contain another phrase, which may contain another phrase. Formal grammars capture this by defining symbols recursively. A noun phrase may contain a noun. It may also contain a noun phrase modified by another phrase. A mathematical expression may contain subexpressions, each of which is itself an expression.

Recursive grammar is central to logic, programming languages, linguistics, formal language theory, parsing, proof systems, and symbolic mathematics. A compiler parses code through recursive syntactic structure. A theorem prover manipulates formulas recursively. A symbolic algebra system represents expressions as trees whose subexpressions are recursively structured.

Recursive grammar shows that recursion is not only numerical. It is one of the basic ways symbolic systems generate complexity from finite rules.

Back to top ↑

Recursive Definitions in Logic and Foundations

Recursive definitions are central to mathematical logic and foundations. The natural numbers can be defined recursively from zero and a successor operation. Formulas in a formal language are defined recursively from atomic formulas and logical connectives. Proofs are finite structures built from axioms and inference rules. Computable functions are often characterized through recursive procedures.

This foundational role matters because recursion helps explain how infinite structures can be generated by finite rules. The set of natural numbers is infinite, but its generative rule is simple. The set of well-formed formulas in a logic may be infinite, but the grammar defining them can be finite. The space of computable procedures may be vast, but it can be studied through formal rules of construction.

Recursive definitions also raise subtle questions. A definition must be well-founded. It must not depend on itself in a circular way that prevents meaning. The recursive step must move toward something already defined or structurally smaller. In foundations, this concern appears as well-founded recursion, primitive recursion, general recursion, fixed points, and computability theory.

Recursion is therefore not just an applied technique. It is part of the architecture of formal mathematics itself.

Back to top ↑

Recursive Modeling in Systems, Data, and AI

Recursive thinking appears throughout modern modeling. A system state may depend on previous states. A model may update iteratively. A graph algorithm may explore neighbors recursively. A decision tree may branch recursively. A neural language model generates one token after another, conditioning future output on prior context. A feedback system may loop outputs back into inputs.

Recursive modeling is powerful because many systems evolve through repeated application of rules. However, recursive models require caution. A small error can compound through iteration. A biased update rule can reinforce itself. A feedback loop can amplify instability. A recursive classifier can propagate earlier category mistakes into later decisions. A model that depends on its own outputs may drift away from reality if not grounded.

Recursive modeling requires careful attention to initialization, update rules, stopping conditions, convergence, error propagation, feedback, and interpretation. Recursion gives systems power, but it can also magnify mistakes.

Back to top ↑

Learning Recursive Thinking

Recursion can be difficult to learn because it asks the mind to trust a smaller version of the same problem. Beginners often try to mentally expand every recursive call, which quickly becomes overwhelming. More advanced recursive thinking recognizes the structure: solve the base case, assume the recursive call solves the smaller case, then combine correctly.

Students often struggle with base cases, stopping conditions, stack behavior, overlapping subproblems, and the difference between recursion and iteration. They may understand a recursive formula but not a recursive program, or understand a recursive program but not an induction proof. The goal is to connect these forms as expressions of one structural idea.

Good recursion teaching should use multiple representations: recurrence equations, diagrams, call trees, code traces, proof outlines, tree structures, and verbal explanations. Recursion becomes clearer when learners see that the same idea appears in many forms.

Back to top ↑

A Mathematical Lens: Base, Rule, Reduction, Return

A useful lens for recursive thinking is the sequence: base, rule, reduction, return. The base case gives a direct answer. The recursive rule reduces the problem. The reduction moves toward simpler cases. The return step combines results back into the larger solution.

This lens applies across mathematics and computation. In factorial, the base is \(0!=1\), the rule is \(n!=n(n-1)!\), the reduction is from \(n\) to \(n-1\), and the return multiplies by \(n\). In tree traversal, the base is a leaf or empty tree, the rule is to visit subtrees, the reduction moves from tree to subtree, and the return combines visited results. In induction, the base proves the starting case, the rule proves the step, and the conclusion returns universal truth.

This framework helps make recursion visible. Recursion is not magic or circular reasoning. It is disciplined self-reference controlled by base cases, reduction, and structure.

Back to top ↑

Computational Companion Examples

The companion repository for this article should extend the Mathematical Thinking codebase with examples focused on recursive definitions, recurrence tables, tree traversal, structural induction, divide-and-conquer algorithms, memoization, dynamic programming, recursive grammar, Haskell algebraic data types, SQL schemas, and responsible interpretation of recursive systems. The examples below are compact article-level previews; the repository can expand them into richer professional workflows.

Python: Factorial, Fibonacci, Trees, and Memoization

from dataclasses import dataclass
from functools import lru_cache

def factorial(n: int) -> int:
    if n < 0:
        raise ValueError("factorial is defined here only for nonnegative integers")
    if n == 0:
        return 1
    return n * factorial(n - 1)

@lru_cache(maxsize=None)
def fibonacci(n: int) -> int:
    if n < 0:
        raise ValueError("fibonacci is defined here only for nonnegative integers")
    if n in (0, 1):
        return n
    return fibonacci(n - 1) + fibonacci(n - 2)

@dataclass(frozen=True)
class Tree:
    label: str
    children: tuple["Tree", ...] = ()

def tree_size(tree: Tree) -> int:
    return 1 + sum(tree_size(child) for child in tree.children)

def tree_depth(tree: Tree) -> int:
    if not tree.children:
        return 1
    return 1 + max(tree_depth(child) for child in tree.children)

proof_tree = Tree(
    "theorem",
    (
        Tree("lemma 1", (Tree("definition"),)),
        Tree("lemma 2")
    )
)

print("5! =", factorial(5))
print("Fibonacci(10) =", fibonacci(10))
print("tree size =", tree_size(proof_tree))
print("tree depth =", tree_depth(proof_tree))

R: Recurrence Table and Recursive Growth Audit

fibonacci_iterative <- function(n) {
  if (n == 0) return(0)
  if (n == 1) return(1)

  previous <- 0
  current <- 1

  for (i in 2:n) {
    next_value <- previous + current
    previous <- current
    current <- next_value
  }

  current
}

audit <- data.frame(
  n = 0:20,
  fibonacci = sapply(0:20, fibonacci_iterative),
  factorial = sapply(0:20, factorial),
  interpretation = "recurrence and product recursion generate values from base cases"
)

print(audit)

Julia: Divide-and-Conquer Recurrence and Memoization

function factorial_recursive(n)
    n < 0 && error("factorial requires nonnegative input")
    n == 0 && return big(1)
    return big(n) * factorial_recursive(n - 1)
end

function fibonacci_memo(n, memo=Dict{Int, BigInt}())
    n < 0 && error("fibonacci requires nonnegative input")
    if n == 0
        return big(0)
    elseif n == 1
        return big(1)
    elseif haskey(memo, n)
        return memo[n]
    end

    memo[n] = fibonacci_memo(n - 1, memo) + fibonacci_memo(n - 2, memo)
    return memo[n]
end

function merge_sort(values)
    length(values) <= 1 && return values
    midpoint = length(values) ÷ 2
    left = merge_sort(values[1:midpoint])
    right = merge_sort(values[(midpoint + 1):end])
    return sort(vcat(left, right))
end

println("10! = ", factorial_recursive(10))
println("Fibonacci(40) = ", fibonacci_memo(40))
println("Sorted values = ", merge_sort([5, 2, 8, 1, 3]))

Haskell: Recursive Data Types and Structural Recursion

{-# OPTIONS_GHC -Wall #-}

data Tree a
  = Leaf a
  | Node a [Tree a]
  deriving (Eq, Show)

factorial :: Integer -> Integer
factorial n
  | n < 0 = error "factorial requires nonnegative input"
  | n == 0 = 1
  | otherwise = n * factorial (n - 1)

fibonacci :: Integer -> Integer
fibonacci n
  | n < 0 = error "fibonacci requires nonnegative input"
  | n == 0 = 0
  | n == 1 = 1
  | otherwise = fibonacci (n - 1) + fibonacci (n - 2)

treeSize :: Tree a -> Int
treeSize tree =
  case tree of
    Leaf _ -> 1
    Node _ children -> 1 + sum (map treeSize children)

treeDepth :: Tree a -> Int
treeDepth tree =
  case tree of
    Leaf _ -> 1
    Node _ children -> 1 + maximum (map treeDepth children)

main :: IO ()
main = do
  let proofTree = Node "theorem" [Node "lemma" [Leaf "definition"], Leaf "case"]
  print (factorial 5)
  print (fibonacci 10)
  print (treeSize proofTree)
  print (treeDepth proofTree)

SQL: Recursive Structure Metadata Schema

CREATE TABLE recursive_definition (
  definition_id TEXT PRIMARY KEY,
  name TEXT NOT NULL,
  base_case TEXT NOT NULL,
  recursive_rule TEXT NOT NULL,
  termination_measure TEXT NOT NULL,
  interpretation TEXT NOT NULL
);

CREATE TABLE recurrence_record (
  recurrence_id TEXT PRIMARY KEY,
  name TEXT NOT NULL,
  initial_values TEXT NOT NULL,
  recurrence_rule TEXT NOT NULL,
  proof_status TEXT NOT NULL
);

CREATE TABLE recursive_structure_warning (
  warning_id TEXT PRIMARY KEY,
  definition_id TEXT NOT NULL,
  warning TEXT NOT NULL,
  mitigation TEXT NOT NULL,
  FOREIGN KEY (definition_id) REFERENCES recursive_definition(definition_id)
);

CREATE TABLE recursive_model_audit (
  model_id TEXT PRIMARY KEY,
  name TEXT NOT NULL,
  state_definition TEXT NOT NULL,
  update_rule TEXT NOT NULL,
  stopping_condition TEXT NOT NULL,
  risk_note TEXT NOT NULL
);

These examples treat recursion as executable structure. Recursive definitions can be represented, recurrence tables can be generated, trees can be traversed, memoization can prevent repeated subproblem work, and SQL schemas can document base cases, rules, stopping conditions, and risks. The goal is not to reduce recursive thought to code, but to make its structure explicit and inspectable.

Back to top ↑

GitHub Repository

The companion repository for this article is designed as a reproducible mathematical-thinking workspace focused on recursive definitions, recurrence relations, induction, tree structures, divide-and-conquer algorithms, dynamic programming, memoization, recursive grammar, Haskell algebraic data types, SQL schemas, and responsible interpretation of recursive systems.

Back to top ↑

Recursive Systems and Responsible Interpretation

Recursive systems are powerful because they propagate structure. A small rule can generate a large pattern. A local update can shape a system over many steps. A recursive algorithm can traverse vast data structures. A feedback loop can reinforce behavior. An AI system can produce outputs that influence future inputs, which then influence future outputs.

This power creates responsibility. Recursion can amplify errors. If the base case is wrong, everything built on it may be wrong. If the update rule is biased, repeated application can magnify bias. If stopping conditions are unclear, a system may continue producing outputs beyond its valid domain. If a recursive model feeds on its own outputs, it may become self-confirming rather than truth-seeking.

Responsible recursive thinking asks: What is the base case? What rule is repeated? What measure decreases or changes? What is preserved? What is amplified? What stops the process? What happens when the recursive output influences future input?

Recursion should clarify structure, not hide compounding error behind repetition.

Back to top ↑

Why Recursion Matters

Recursion matters because it shows how large structures can arise from small rules. It explains how sequences unfold, how trees grow, how proofs propagate, how algorithms divide problems, how grammars generate language, how models update, and how symbolic systems create complexity from finite definitions.

It also matters because recursion is central to modern computation. Data structures are recursive. Programs parse recursive grammars. Algorithms traverse trees and graphs recursively. Dynamic programming improves recursive computation. AI systems generate symbolic sequences through repeated update and conditioning. Databases and document formats store nested structures. Recursive thinking is therefore foundational for understanding digital systems.

Mathematically, recursion connects definition, proof, computation, and structure. A recursive definition says how an object is built. An induction proof says why a property holds for all built objects. A recursive algorithm says how to compute by reducing. A recursive data type says how structure contains substructure.

Recursive thinking trains the mind to ask disciplined questions: Where does the process begin? How does it reduce? What remains invariant? What is returned? Why does it stop? What grows? What repeats? What is amplified?

Recursion is not circular confusion. It is controlled self-reference. It is the mathematics of structures that contain smaller versions of themselves, processes that proceed by reduction, and systems whose futures depend on their pasts.

Back to top ↑

Related Articles

• What Is Mathematical Thinking? Pattern, Proof, Architecture, and Reason
• Graphs, Networks, and Discrete Structure
• Discrete Mathematics and the Logic of Structure
• Combinatorics and the Mathematics of Possibility
• Sets, Relations, and Functions as Modes of Thought
• Logic and the Structure of Formal Inference
• Proof and the Logic of Mathematical Justification
• Patterns, Structure, and the Mathematical Imagination
• Mathematical Thinking for Computer Science
• Algorithms, Proof, and Formal Reasoning

Further Reading

• Abelson, H., Sussman, G.J. and Sussman, J. (1996) Structure and Interpretation of Computer Programs. 2nd edn. Cambridge, MA: MIT Press. Available at: https://mitpress.mit.edu/9780262510875/structure-and-interpretation-of-computer-programs/
• Cormen, T.H., Leiserson, C.E., Rivest, R.L. and Stein, C. (2022) Introduction to Algorithms. 4th edn. Cambridge, MA: MIT Press. Available at: https://mitpress.mit.edu/9780262046305/introduction-to-algorithms/
• Felleisen, M., Findler, R.B., Flatt, M. and Krishnamurthi, S. (2018) How to Design Programs. 2nd edn. Cambridge, MA: MIT Press. Available at: https://htdp.org/
• Graham, R.L., Knuth, D.E. and Patashnik, O. (1994) Concrete Mathematics: A Foundation for Computer Science. 2nd edn. Reading, MA: Addison-Wesley.
• Hutton, G. (2016) Programming in Haskell. 2nd edn. Cambridge: Cambridge University Press. Available at: https://www.cambridge.org/highereducation/books/programming-in-haskell/8FED82E807EF12D390DE0D16FDE217E4
• Knuth, D.E. (1997) The Art of Computer Programming, Volume 1: Fundamental Algorithms. 3rd edn. Boston: Addison-Wesley.
• Rosen, K.H. (2019) Discrete Mathematics and Its Applications. 8th edn. New York: McGraw-Hill.
• Sipser, M. (2013) Introduction to the Theory of Computation. 3rd edn. Boston: Cengage Learning.

Back to top ↑

References

• Abelson, H., Sussman, G.J. and Sussman, J. (1996) Structure and Interpretation of Computer Programs. 2nd edn. Cambridge, MA: MIT Press. Available at: https://mitpress.mit.edu/9780262510875/structure-and-interpretation-of-computer-programs/
• Cormen, T.H., Leiserson, C.E., Rivest, R.L. and Stein, C. (2022) Introduction to Algorithms. 4th edn. Cambridge, MA: MIT Press. Available at: https://mitpress.mit.edu/9780262046305/introduction-to-algorithms/
• Felleisen, M., Findler, R.B., Flatt, M. and Krishnamurthi, S. (2018) How to Design Programs. 2nd edn. Cambridge, MA: MIT Press. Available at: https://htdp.org/
• Graham, R.L., Knuth, D.E. and Patashnik, O. (1994) Concrete Mathematics: A Foundation for Computer Science. 2nd edn. Reading, MA: Addison-Wesley.
• Hutton, G. (2016) Programming in Haskell. 2nd edn. Cambridge: Cambridge University Press. Available at: https://www.cambridge.org/highereducation/books/programming-in-haskell/8FED82E807EF12D390DE0D16FDE217E4
• Knuth, D.E. (1997) The Art of Computer Programming, Volume 1: Fundamental Algorithms. 3rd edn. Boston: Addison-Wesley.
• Rosen, K.H. (2019) Discrete Mathematics and Its Applications. 8th edn. New York: McGraw-Hill.
• Sipser, M. (2013) Introduction to the Theory of Computation. 3rd edn. Boston: Cengage Learning.

Back to top ↑