Logic and Computation: How Formal Reasoning Shapes Algorithms

Last Updated June 17, 2026

Logic gives computation one of its deepest foundations. Before a program can calculate, search, sort, verify, infer, classify, or decide, it must distinguish conditions, rules, cases, states, claims, and consequences. Logic provides formal tools for doing that. It helps computation represent what is true or false, what follows from what, when a condition holds, when a rule applies, when a proof is valid, and when a procedure has satisfied its requirements.

Computation is not only arithmetic. It is also structured reasoning. Programs evaluate conditions, combine rules, test predicates, branch on truth values, enforce constraints, verify invariants, query databases, prove properties, infer consequences, and decide whether statements can be satisfied. These are logical activities, even when they appear inside ordinary software.

Logic and computation are therefore deeply connected. Logic helps make reasoning precise. Computation makes formal reasoning executable. Together, they shape algorithms, programming languages, databases, artificial intelligence, verification, type systems, digital circuits, constraint solving, theorem proving, and responsible automated decision systems.

This article explains how logic supports computational reasoning. It introduces propositions, predicates, truth values, conditionals, rules, inference, proof, satisfiability, Boolean algebra, specifications, type systems, verification, logic programming, databases, and artificial intelligence. It also emphasizes that logic is not merely abstract symbolism. In computation, logic becomes operational: it directs program control, validates states, constrains search, supports correctness, and helps people reason about what systems are doing.

Why Logic Matters for Computation

Logic matters for computation because computational systems must make distinctions. A program must decide whether input is valid or invalid, whether a condition is true or false, whether a rule applies or does not apply, whether a search should continue or stop, whether a state is allowed or impossible, whether a result satisfies a requirement, and whether an output follows from available information.

These distinctions are logical. They may be implemented through code, hardware, queries, rules, constraints, or type systems, but they all depend on formal relationships among statements and conditions.

Logic gives computation a language of precision. It helps transform vague expectations into explicit conditions, rules, and consequences.

Back to top ↑

What Logic Contributes to Computational Reasoning

Logic contributes structure. It helps computational reasoning move from informal claims to formal relationships. Instead of saying “the system should behave sensibly,” logic asks what must be true, what may be true, what cannot be true, what follows from assumptions, and what should happen when conditions hold.

Logic supports several central computational tasks:

• representing statements and conditions;
• combining truth values through operators such as and, or, and not;
• expressing rules and implications;
• checking whether constraints are satisfied;
• reasoning from premises to conclusions;
• proving that a program satisfies a specification;
• detecting inconsistency or impossible states;
• separating valid inference from unsupported assumption.

Logic is not opposed to computation. It is one of the ways computation becomes intelligible.

Back to top ↑

Propositions, Predicates, and Truth Values

A proposition is a statement that can be evaluated as true or false. In computation, propositions appear as Boolean values, test assertions, conditional checks, feature flags, invariants, database conditions, and rule outcomes.

A predicate is a condition that depends on one or more values. For example, “the record is complete” may depend on the fields inside a record. “The number is positive” depends on the value of a number. “The user is eligible” may depend on many conditions, rules, and institutional definitions.

These logical forms appear throughout ordinary programming. A programmer may not write them in symbolic notation, but the reasoning is still present in conditions, loops, assertions, filters, and tests.

Back to top ↑

Conditionals, Rules, and Control Flow

Conditionals are one of the clearest links between logic and programming. A conditional statement directs execution according to whether a condition holds. In ordinary programming, this appears as if, else, switch, pattern matching, guards, filters, rules, and decision tables.

IF record is incomplete THEN
    return warning
ELSE IF record is valid AND score exceeds threshold THEN
    route for review
ELSE
    return standard result
END IF

This is logical structure expressed procedurally. The program is not merely moving line by line. It is evaluating conditions and selecting paths based on truth values.

Logic helps make control flow reviewable. It asks whether branches are exhaustive, whether rules conflict, whether conditions overlap, and whether defaults are safe.

Back to top ↑

Inference, Proof, and Correctness

Inference is the movement from premises to conclusions. In computation, inference appears in rule systems, theorem provers, type checkers, expert systems, planning systems, database reasoning, static analysis, verification, and artificial intelligence.

A proof is a structured demonstration that a conclusion follows from assumptions. Program correctness often depends on a proof-like relationship between what is assumed before a program runs and what should be true after it completes.

This does not mean every program requires a formal proof. But correctness reasoning matters even in everyday programming. A test is a small correctness claim. A type error is a failed consistency claim. An invariant is a property that should remain true. A specification defines expected behavior. A regression test preserves evidence from an earlier failure.

Correctness is not only a technical property. It is a relationship between purpose, assumptions, implementation, and evidence.

Back to top ↑

Boolean Logic and Digital Computation

Boolean logic is central to digital computation. At the hardware level, logic gates combine binary signals. At the software level, Boolean values direct conditions, filters, flags, permissions, validation checks, and tests.

Boolean algebra provides operations such as AND, OR, NOT, XOR, NAND, and NOR. These operations can be implemented in circuits, represented in truth tables, and expressed in programming languages.

Boolean logic can look simple, but errors in Boolean conditions are common. A misplaced negation, unclear operator precedence, incomplete case distinction, or unsafe default can change program behavior dramatically. Debugging often begins by asking whether the program evaluated the intended logical condition.

Back to top ↑

Logic Programming and Declarative Reasoning

Logic programming makes the relationship between logic and computation explicit. Instead of writing step-by-step instructions, a logic program declares facts and rules. The system then attempts to infer answers from those facts and rules.

A simple logic-programming idea might look like this:

fact: parent(alice, ben)
fact: parent(ben, clara)

rule: grandparent(X, Z) is true if
      parent(X, Y) is true
      and parent(Y, Z) is true

The program does not describe every procedural step in the same way an imperative program would. It defines relationships. Computation becomes the process of finding what follows.

Declarative reasoning is useful when the problem is naturally expressed as relationships, rules, constraints, or inference. It appears in expert systems, planning, knowledge representation, type inference, database queries, configuration systems, and verification tools.

Back to top ↑

Databases, Queries, and Constraints

Databases are deeply logical systems. A relational database stores structured facts in tables. A query asks for records satisfying specified conditions. Constraints define what combinations of values are allowed. Joins express relationships among tables.

SQL may not look like symbolic logic at first glance, but it is built on logical operations: selection, projection, conjunction, disjunction, negation, existential relationships, and set operations.

SELECT article_title
FROM articles
WHERE series = 'Algorithms'
  AND status = 'published'
  AND review_required = false;

This query describes a logical condition: return article titles where several predicates hold at once.

Database logic is especially important because many institutional systems depend on stored records. If the logical structure of the database is weak, the system can produce errors even when the application code appears correct.

Back to top ↑

Types, Specifications, and Verification

Type systems, specifications, and verification tools bring logic into programming languages. A type system restricts what values can be used where. A specification states what a program is supposed to do. Verification attempts to show that implementation satisfies specification.

Types are not only labels. They are logical constraints. If a function requires a number, passing a string violates the expected relation. If a result may be either success or failure, a type can force the program to handle both cases. Stronger type systems can encode more assumptions, making certain errors impossible or harder to express.

Verification is not always necessary for every small script, but verification thinking is broadly useful. It asks what must be true, how we know, and what evidence supports the claim.

Back to top ↑

Limits of Formal Logic in Real Systems

Logic is powerful, but it does not solve every computational problem by itself. Real systems involve ambiguity, uncertainty, incomplete data, conflicting goals, institutional context, human interpretation, social consequences, and changing environments. Not every value can be reduced to a clean predicate without loss.

Formal logic works best when assumptions, definitions, and relationships can be stated clearly. But many real-world systems involve categories that are contested, measurements that are imperfect, and decisions that require judgment.

Logic helps make reasoning precise. It should not be mistaken for complete understanding. Computational systems still require interpretation, governance, and human judgment.

Back to top ↑

Back to top ↑

Mathematics, Computation, and Modeling

Logic and computation can be represented through relationships among statements, rules, models, and consequences.

A basic implication has the form:

A set of assumptions can entail a conclusion:

A computational rule system can be expressed as:

A constraint satisfaction problem can be expressed as:

These forms appear in programming languages, solvers, type systems, databases, theorem provers, and verification tools. They show how logic makes computation both executable and reviewable.

Back to top ↑

Python Workflow: Logic and Computation Audit

The Python workflow below creates a simple synthetic audit for computational logic cases. It scores rule clarity, predicate definition, input validity, contradiction risk, inference traceability, constraint coverage, testability, verification readiness, explainability, and governance readiness.

# logic_computation_audit.py
# Dependency-light workflow for evaluating logic in computational systems.

from __future__ import annotations

from dataclasses import asdict, dataclass
from pathlib import Path
import csv
import json
from statistics import mean

ARTICLE_ROOT = Path(__file__).resolve().parents[1]
TABLES = ARTICLE_ROOT / "outputs" / "tables"
JSON_DIR = ARTICLE_ROOT / "outputs" / "json"


@dataclass(frozen=True)
class LogicCase:
    case_name: str
    system_context: str
    logical_structure: str
    rule_clarity: float
    predicate_definition: float
    input_validity: float
    contradiction_control: float
    inference_traceability: float
    constraint_coverage: float
    testability: float
    verification_readiness: float
    explainability: float
    governance_readiness: float


def clamp(value: float, low: float = 0.0, high: float = 100.0) -> float:
    return max(low, min(high, value))


def logic_quality(case: LogicCase) -> float:
    return clamp(
        100.0 * (
            0.12 * case.rule_clarity
            + 0.12 * case.predicate_definition
            + 0.10 * case.input_validity
            + 0.10 * case.contradiction_control
            + 0.12 * case.inference_traceability
            + 0.10 * case.constraint_coverage
            + 0.10 * case.testability
            + 0.08 * case.verification_readiness
            + 0.08 * case.explainability
            + 0.08 * case.governance_readiness
        )
    )


def logic_risk(case: LogicCase) -> float:
    weak_points = [
        1.0 - case.rule_clarity,
        1.0 - case.predicate_definition,
        1.0 - case.input_validity,
        1.0 - case.contradiction_control,
        1.0 - case.inference_traceability,
        1.0 - case.constraint_coverage,
        1.0 - case.testability,
        1.0 - case.explainability,
    ]
    return clamp(100.0 * mean(weak_points))


def diagnose(quality: float, risk: float) -> str:
    if quality >= 80 and risk <= 25:
        return "strong logical structure with traceable inference and low contradiction risk"
    if quality >= 65 and risk <= 40:
        return "usable logical structure with review needs"
    if risk >= 55:
        return "high logic risk; rules, predicates, or constraints may be unclear or inconsistent"
    return "partial logical structure; improve definitions, traceability, tests, or governance"


def build_cases() -> list[LogicCase]:
    return [
        LogicCase(
            case_name="Input validation rules",
            system_context="Form validation and data-quality gate.",
            logical_structure="Predicates over required fields, formats, and allowed ranges.",
            rule_clarity=0.82,
            predicate_definition=0.84,
            input_validity=0.80,
            contradiction_control=0.76,
            inference_traceability=0.68,
            constraint_coverage=0.78,
            testability=0.82,
            verification_readiness=0.62,
            explainability=0.78,
            governance_readiness=0.70,
        ),
        LogicCase(
            case_name="Database query constraints",
            system_context="Relational database with joins and integrity constraints.",
            logical_structure="Selection predicates, foreign keys, uniqueness, and check constraints.",
            rule_clarity=0.78,
            predicate_definition=0.80,
            input_validity=0.76,
            contradiction_control=0.74,
            inference_traceability=0.72,
            constraint_coverage=0.82,
            testability=0.76,
            verification_readiness=0.66,
            explainability=0.70,
            governance_readiness=0.72,
        ),
        LogicCase(
            case_name="Decision-rule workflow",
            system_context="Institutional routing workflow using explicit rules.",
            logical_structure="If-then rules, exceptions, review states, and escalation paths.",
            rule_clarity=0.74,
            predicate_definition=0.70,
            input_validity=0.72,
            contradiction_control=0.62,
            inference_traceability=0.68,
            constraint_coverage=0.66,
            testability=0.72,
            verification_readiness=0.58,
            explainability=0.76,
            governance_readiness=0.78,
        ),
        LogicCase(
            case_name="Program invariant checks",
            system_context="Algorithm with state transitions and runtime assertions.",
            logical_structure="Preconditions, postconditions, loop invariants, and assertions.",
            rule_clarity=0.80,
            predicate_definition=0.78,
            input_validity=0.74,
            contradiction_control=0.76,
            inference_traceability=0.74,
            constraint_coverage=0.72,
            testability=0.80,
            verification_readiness=0.76,
            explainability=0.68,
            governance_readiness=0.66,
        ),
    ]


def run_audit() -> list[dict[str, object]]:
    rows: list[dict[str, object]] = []
    for case in build_cases():
        quality = logic_quality(case)
        risk = logic_risk(case)
        rows.append({
            **asdict(case),
            "logic_quality": round(quality, 3),
            "logic_risk": round(risk, 3),
            "diagnostic": diagnose(quality, risk),
        })
    return rows


def write_csv(path: Path, rows: list[dict[str, object]]) -> None:
    path.parent.mkdir(parents=True, exist_ok=True)
    with path.open("w", newline="", encoding="utf-8") as handle:
        writer = csv.DictWriter(handle, fieldnames=list(rows[0].keys()))
        writer.writeheader()
        writer.writerows(rows)


def write_json(path: Path, payload: object) -> None:
    path.parent.mkdir(parents=True, exist_ok=True)
    path.write_text(json.dumps(payload, indent=2, sort_keys=True), encoding="utf-8")


def summarize(rows: list[dict[str, object]]) -> dict[str, object]:
    return {
        "case_count": len(rows),
        "average_logic_quality": round(mean(float(row["logic_quality"]) for row in rows), 3),
        "average_logic_risk": round(mean(float(row["logic_risk"]) for row in rows), 3),
        "highest_quality_case": max(rows, key=lambda row: float(row["logic_quality"]))["case_name"],
        "highest_risk_case": max(rows, key=lambda row: float(row["logic_risk"]))["case_name"],
        "interpretation": "Logic quality depends on clear rules, well-defined predicates, valid inputs, contradiction control, traceable inference, constraint coverage, testability, verification readiness, explainability, and governance."
    }


def main() -> None:
    rows = run_audit()
    summary = summarize(rows)

    write_csv(TABLES / "logic_computation_audit.csv", rows)
    write_csv(TABLES / "logic_computation_audit_summary.csv", [summary])
    write_json(JSON_DIR / "logic_computation_audit.json", rows)
    write_json(JSON_DIR / "logic_computation_audit_summary.json", summary)

    print("Logic and computation audit complete.")
    print(TABLES / "logic_computation_audit.csv")


if __name__ == "__main__":
    main()

This workflow treats logic as a reviewable part of computational systems. It asks whether rules are clear, predicates are defined, constraints are complete, inference is traceable, and contradictions are controlled.

Back to top ↑

R Workflow: Logical Structure Summary

The R workflow reads the Python-generated audit table and creates summary outputs and visualizations using base R. It compares logic quality and logic risk across synthetic computational cases.

# logic_computation_summary.R
# Base R workflow for summarizing logic quality and logic risk.

args <- commandArgs(trailingOnly = FALSE)
file_arg <- grep("^--file=", args, value = TRUE)

if (length(file_arg) > 0) {
  script_path <- normalizePath(sub("^--file=", "", file_arg[1]), mustWork = TRUE)
  article_root <- normalizePath(file.path(dirname(script_path), ".."), mustWork = TRUE)
} else {
  article_root <- getwd()
}

setwd(article_root)

tables_dir <- file.path(article_root, "outputs", "tables")
figures_dir <- file.path(article_root, "outputs", "figures")

if (!dir.exists(tables_dir)) {
  dir.create(tables_dir, recursive = TRUE)
}

if (!dir.exists(figures_dir)) {
  dir.create(figures_dir, recursive = TRUE)
}

input_path <- file.path(tables_dir, "logic_computation_audit.csv")

if (!file.exists(input_path)) {
  stop(paste("Missing", input_path, "Run the Python workflow first."))
}

data <- read.csv(input_path, stringsAsFactors = FALSE)

summary_table <- data.frame(
  case_count = nrow(data),
  average_logic_quality = mean(data$logic_quality),
  average_logic_risk = mean(data$logic_risk),
  highest_quality_case = data$case_name[which.max(data$logic_quality)],
  highest_risk_case = data$case_name[which.max(data$logic_risk)]
)

write.csv(
  summary_table,
  file.path(tables_dir, "r_logic_computation_summary.csv"),
  row.names = FALSE
)

comparison_matrix <- rbind(
  data$logic_quality,
  data$logic_risk
)

colnames(comparison_matrix) <- data$case_name
rownames(comparison_matrix) <- c("Logic quality", "Logic risk")

png(
  file.path(figures_dir, "logic_quality_vs_risk.png"),
  width = 1400,
  height = 800
)

barplot(
  comparison_matrix,
  beside = TRUE,
  las = 2,
  ylim = c(0, 100),
  ylab = "Score",
  main = "Logic Quality vs. Logic Risk"
)

legend(
  "topleft",
  legend = rownames(comparison_matrix),
  pch = 15,
  bty = "n"
)

grid()
dev.off()

png(
  file.path(figures_dir, "logic_quality_dimensions.png"),
  width = 1400,
  height = 800
)

dimension_means <- colMeans(data[, c(
  "rule_clarity",
  "predicate_definition",
  "input_validity",
  "contradiction_control",
  "inference_traceability",
  "constraint_coverage",
  "testability",
  "verification_readiness",
  "explainability",
  "governance_readiness"
)]) * 100

barplot(
  dimension_means,
  las = 2,
  ylim = c(0, 100),
  ylab = "Average score",
  main = "Average Logic Quality by Dimension"
)

grid()
dev.off()

print(summary_table)

This workflow helps turn logical structure into something that can be reviewed. It can be adapted for rule systems, validation systems, database schemas, decision workflows, and verification-oriented code.

Back to top ↑

GitHub Repository

The companion repository for this article will provide reproducible code, synthetic datasets, workflow documentation, generated outputs, and logic-quality diagnostics that extend the article into executable examples.

articles/logic-and-computation/
├── python/
│   ├── logic_computation_audit.py
│   ├── truth_table_examples.py
│   ├── predicate_validation_examples.py
│   ├── inference_trace_checker.py
│   ├── constraint_satisfaction_examples.py
│   ├── calculators/
│   │   ├── logic_quality_calculator.py
│   │   └── contradiction_risk_calculator.py
│   └── tests/
├── r/
│   ├── logic_computation_summary.R
│   ├── logic_quality_visualization.R
│   └── rule_consistency_report.R
├── julia/
│   ├── logical_constraint_simulation.jl
│   └── truth_table_examples.jl
├── sql/
│   ├── schema_logic_cases.sql
│   ├── schema_rule_systems.sql
│   └── logic_queries.sql
├── haskell/
│   ├── LogicTypes.hs
│   ├── PredicateContracts.hs
│   └── Main.hs
├── rust/
│   └── src/
├── go/
│   └── main.go
├── c/
│   └── logic_computation_audit.c
├── cpp/
│   └── logic_computation_audit.cpp
├── fortran/
│   └── logic_quality_model.f90
├── java/
│   └── src/main/java/org/contentcatalyst/algorithms/
├── typescript/
│   └── src/
├── prolog/
│   └── logic_rules.pl
├── racket/
│   └── logic_interpreter.rkt
├── docs/
│   ├── methodology.md
│   ├── article-notes.md
│   ├── logic-and-computation.md
│   ├── governance-notes.md
│   └── responsible-use.md
├── data/
│   └── synthetic_logic_computation_cases.csv
├── outputs/
│   ├── tables/
│   ├── figures/
│   ├── json/
│   ├── logs/
│   └── reports/
├── notebooks/
│   └── logic_and_computation_walkthrough.ipynb
├── canvas/
│   ├── canvas_manifest.json
│   ├── canvas_cards.json
│   └── canvas_index.md
└── shared/
    ├── schemas/
    ├── templates/
    ├── taxonomies/
    ├── benchmarks/
    └── governance/

Back to top ↑

A Practical Method for Using Logic in Computational Reasoning

A practical method for using logic begins by identifying where a computational system depends on conditions, rules, constraints, or claims. Once those logical structures are visible, they can be reviewed, tested, documented, and governed.

This method makes logic practical. It helps computational teams avoid hidden assumptions, contradictory rules, unsafe defaults, and unreviewed inference paths.

Back to top ↑

Common Pitfalls

A common pitfall is assuming that logical form guarantees responsible use. A rule can be formally clear and still be based on weak definitions, incomplete data, outdated assumptions, or inappropriate goals. Logic improves precision, but precision does not automatically make a system wise.

Another pitfall is hiding complex judgments inside simple predicates. A condition such as is_eligible, is_high_risk, is_relevant, or is_valid may conceal many assumptions. If those assumptions are not documented, the system may appear more objective than it is.

Common pitfalls include:

• vague predicates: using conditions without defining what they mean;
• overbroad defaults: sending all unexpected cases into a catch-all branch;
• hidden negation: using negative conditions that obscure meaning;
• rule conflict: allowing multiple rules to produce incompatible results;
• incomplete cases: failing to cover edge cases or no-solution states;
• false precision: making uncertain categories look formally settled;
• untraceable inference: producing outputs without an explainable path from premises;
• logic without evidence: encoding rules that are not supported by domain knowledge or data;
• logic without governance: deploying rule systems without review, revision, or accountability;
• formalism without judgment: mistaking valid structure for responsible interpretation.

The remedy is not to avoid logic. The remedy is to use logic carefully, document assumptions, test cases, expose limits, and keep human judgment active where meaning and consequence require it.

Back to top ↑

Why Logic and Computation Belong Together

Logic and computation belong together because computation is not only mechanical execution. It is structured reasoning made operational. Programs evaluate conditions, enforce constraints, follow rules, infer consequences, check assertions, query relations, validate states, and attempt to satisfy specifications.

Logic gives computational systems precision. It helps people ask what is true, what follows, what conflicts, what must hold, what can fail, and what should be proven or tested. Computation gives logic operational power. It turns formal relationships into procedures, programs, solvers, databases, circuits, verification systems, and rule-based workflows.

The relationship is not complete without judgment. Formal logic can clarify computational reasoning, but real systems also require interpretation, context, evidence, documentation, and governance. Used well, logic makes computation more understandable, testable, explainable, and responsible.

Back to top ↑

Related Articles

• What Is Algorithms & Computational Reasoning?
• Algorithmic Thinking vs. Computational Reasoning
• Problems, Procedures, and Formalization
• Decomposition and Stepwise Reasoning
• Abstraction in Computational Reasoning
• Inputs, Outputs, States, and Stopping Conditions
• From Pseudocode to Programs
• Debugging as Computational Reasoning

Further Reading

• Barwise, J. and Etchemendy, J. (1999) Language, Proof and Logic. Stanford, CA: CSLI Publications. Publisher information available at: CSLI Publications.
• Ben-Ari, M. (2012) Mathematical Logic for Computer Science. 3rd edn. London: Springer. Available at: SpringerLink.
• Boolos, G.S., Burgess, J.P. and Jeffrey, R.C. (2007) Computability and Logic. 5th edn. Cambridge: Cambridge University Press. Available at: Cambridge University Press.
• Enderton, H.B. (2001) A Mathematical Introduction to Logic. 2nd edn. San Diego, CA: Academic Press. Publisher information available at: Elsevier.
• Gallier, J.H. (2015) Logic for Computer Science: Foundations of Automatic Theorem Proving. 2nd edn. Mineola, NY: Dover. Author materials available at: University of Pennsylvania.
• Huth, M. and Ryan, M. (2004) Logic in Computer Science: Modelling and Reasoning about Systems. 2nd edn. Cambridge: Cambridge University Press. Available at: Cambridge University Press.
• Lloyd, J.W. (1987) Foundations of Logic Programming. 2nd edn. Berlin: Springer. Available at: SpringerLink.
• Mitchell, J.C. (1996) Foundations for Programming Languages. Cambridge, MA: MIT Press. Available at: MIT Press.
• Pierce, B.C. (2002) Types and Programming Languages. Cambridge, MA: MIT Press. Available at: MIT Press.
• Robinson, J.A. (1965) ‘A machine-oriented logic based on the resolution principle’, Journal of the ACM, 12(1), pp. 23–41. Available at: ACM Digital Library.
• Sipser, M. (2012) Introduction to the Theory of Computation. 3rd edn. Boston, MA: Cengage Learning. Author information available at: MIT Mathematics.
• Smullyan, R.M. (1995) First-Order Logic. Mineola, NY: Dover Publications. Publisher information available at: Dover Publications.
• van Benthem, J. (2011) Logical Dynamics of Information and Interaction. Cambridge: Cambridge University Press. Available at: Cambridge University Press.
• Whitehead, A.N. and Russell, B. (1910–1913) Principia Mathematica. Cambridge: Cambridge University Press. Digitized volumes available through: Internet Archive.

References

• Barwise, J. and Etchemendy, J. (1999) Language, Proof and Logic. Stanford, CA: CSLI Publications. Publisher information available at: https://web.stanford.edu/group/cslipublications/cslipublications/site/157586374X.shtml.
• Ben-Ari, M. (2012) Mathematical Logic for Computer Science. 3rd edn. London: Springer. Available at: https://link.springer.com/book/10.1007/978-1-4471-4129-7.
• Boolos, G.S., Burgess, J.P. and Jeffrey, R.C. (2007) Computability and Logic. 5th edn. Cambridge: Cambridge University Press. Available at: https://www.cambridge.org/core/books/computability-and-logic/8E4F7BCE3A7BCA55284D86D06BE1D983.
• Enderton, H.B. (2001) A Mathematical Introduction to Logic. 2nd edn. San Diego, CA: Academic Press. Publisher information available at: https://www.elsevier.com/books/a-mathematical-introduction-to-logic/enderton/978-0-12-238452-3.
• Gallier, J.H. (2015) Logic for Computer Science: Foundations of Automatic Theorem Proving. 2nd edn. Mineola, NY: Dover. Author materials available at: https://www.cis.upenn.edu/~jean/gbooks/logic.html.
• Hoare, C.A.R. (1969) ‘An axiomatic basis for computer programming’, Communications of the ACM, 12(10), pp. 576–580. doi: 10.1145/363235.363259.
• Huth, M. and Ryan, M. (2004) Logic in Computer Science: Modelling and Reasoning about Systems. 2nd edn. Cambridge: Cambridge University Press. Available at: https://www.cambridge.org/core/books/logic-in-computer-science/2A99F074DDF91A7436C01B63BCA7D345.
• Lloyd, J.W. (1987) Foundations of Logic Programming. 2nd edn. Berlin: Springer. Available at: https://link.springer.com/book/10.1007/978-3-642-83189-8.
• Mitchell, J.C. (1996) Foundations for Programming Languages. Cambridge, MA: MIT Press. Available at: https://mitpress.mit.edu/9780262133210/foundations-for-programming-languages/.
• Pierce, B.C. (2002) Types and Programming Languages. Cambridge, MA: MIT Press. Available at: https://mitpress.mit.edu/9780262162098/types-and-programming-languages/.
• Robinson, J.A. (1965) ‘A machine-oriented logic based on the resolution principle’, Journal of the ACM, 12(1), pp. 23–41. doi: 10.1145/321250.321253.
• Sipser, M. (2012) Introduction to the Theory of Computation. 3rd edn. Boston, MA: Cengage Learning. Author information available at: https://math.mit.edu/~sipser/book.html.
• Smullyan, R.M. (1995) First-Order Logic. Mineola, NY: Dover Publications. Publisher information available at: https://store.doverpublications.com/products/9780486683706.
• van Benthem, J. (2011) Logical Dynamics of Information and Interaction. Cambridge: Cambridge University Press. Available at: https://www.cambridge.org/core/books/logical-dynamics-of-information-and-interaction/80176E34170F7F132D9BCA8E75D31988.
• Whitehead, A.N. and Russell, B. (1910–1913) Principia Mathematica. Cambridge: Cambridge University Press. Digitized volume available through: https://archive.org/details/PrincipiaMathematicaVolumeI.

Back to top ↑