Formal Languages and Symbolic Representation: How Symbols Become Computable

Last Updated June 17, 2026

Formal languages give computation a way to represent structure precisely. A computer cannot work directly with vague intention. It works with symbols, strings, tokens, rules, expressions, encodings, grammars, syntax trees, schemas, instructions, and formally interpretable patterns. Formal languages make those structures explicit.

This matters because computation is not only about numbers. It is also about representation. Programs, mathematical expressions, database queries, markup, regular expressions, logic formulas, type declarations, configuration files, data schemas, proofs, protocols, and machine instructions all depend on symbolic forms that can be parsed, checked, transformed, interpreted, or executed.

Formal languages help explain how symbolic expression becomes computational action. A language defines what counts as a valid expression. A grammar defines how expressions are built. A parser checks and organizes those expressions. An interpreter, compiler, solver, theorem prover, database engine, or runtime system gives them operational meaning. Symbolic representation is the bridge between human-readable structure and machine-processable procedure.

This article explains formal languages and symbolic representation as foundations of computational reasoning. It introduces alphabets, symbols, strings, languages, grammars, syntax, semantics, tokens, parsing, regular languages, context-free languages, syntax trees, compilers, interpreters, data formats, markup, schemas, logic formulas, and programming languages. It also explains why symbolic representation is not merely technical notation. The way symbols are defined, structured, interpreted, and governed shapes what computational systems can express, check, automate, and explain.

Why Formal Languages Matter

Formal languages matter because computation needs unambiguous structure. Human language is rich, flexible, contextual, metaphorical, and often ambiguous. Computation requires symbols arranged according to rules that can be checked and processed. A formal language defines which symbolic expressions are allowed and how they are structured.

This is why formal languages appear everywhere in computational systems. Programming languages define valid programs. Query languages define valid database requests. Markup languages define structured documents. Logic languages define valid formulas. Configuration languages define system settings. Data formats define how information is serialized. Protocols define valid message exchanges.

Formal languages allow computational systems to reject malformed input, parse valid expressions, preserve structure, transform representations, and attach operational meaning to symbols.

Back to top ↑

What Is a Formal Language?

A formal language is a set of strings built from an alphabet according to specified rules. The alphabet defines the symbols available. The rules define which combinations of symbols belong to the language.

Unlike natural languages, formal languages are designed for precise recognition and manipulation. They do not depend on ordinary context in the same way human speech does. A string either belongs to the formal language or it does not, at least under a particular grammar or recognition rule.

A formal language is therefore both restrictive and enabling. It restricts what counts as valid, and that restriction makes reliable computational processing possible.

Back to top ↑

Symbols, Alphabets, and Strings

Symbols are the basic units of formal representation. An alphabet is the set of symbols available for forming strings. A string is a finite sequence of symbols. These simple ideas support programming languages, data formats, expressions, protocols, and symbolic reasoning systems.

In practice, symbols often appear as tokens rather than raw characters. A programming language may treat while, identifier, number, +, and ; as tokens. A parser then reasons over these tokens rather than individual characters.

Symbolic representation becomes powerful when levels are connected carefully. A system that confuses characters, tokens, expressions, statements, and documents can misread input or misinterpret meaning.

Back to top ↑

Grammars and Rules

A grammar defines how strings in a language can be generated or recognized. It describes the structure of valid expressions. In computational practice, grammars are used to define programming languages, query languages, markup languages, command languages, data formats, and domain-specific languages.

A grammar usually includes terminal symbols, nonterminal symbols, production rules, and a start symbol. Terminals are the symbols that appear in final strings. Nonterminals represent abstract categories. Production rules define how categories expand into symbols or other categories. The start symbol identifies where generation begins.

A simple expression grammar might look like this:

Expression → Term
Expression → Expression + Term
Term       → Number
Term       → Identifier
Term       → ( Expression )

This grammar defines valid expression structures. It can produce strings such as x, 3, x + 3, or (x + 3). A parser can use the grammar to check whether an input string is valid and to build a syntax tree.

Grammars make symbolic structure visible. They show not only which strings are valid, but how valid strings are built.

Back to top ↑

Syntax, Semantics, and Interpretation

Syntax concerns form. Semantics concerns meaning. A string can be syntactically valid while semantically invalid, ambiguous, unsafe, or inappropriate. This distinction is central to computational reasoning.

For example, a program may have valid syntax but still divide by zero. A SQL query may be syntactically valid but return the wrong rows. A JSON document may be well-formed but fail a schema requirement. A logical formula may be well-formed but false under a particular interpretation.

Formal languages help with syntax and structure, but semantics requires interpretation. Some semantics can be formalized. Some meaning depends on domain context, institutional rules, human judgment, and responsible use.

Back to top ↑

Tokens, Parsing, and Structure

Parsing is the process of analyzing a string according to a grammar. A parser takes a sequence of symbols or tokens and determines whether it belongs to a language. If the string is valid, the parser may produce a parse tree or abstract syntax tree that captures structure.

This process appears in compilers, interpreters, query engines, template systems, markup processors, command-line tools, expression evaluators, and data validators.

source text
   ↓
lexical analysis
   ↓
tokens
   ↓
parsing
   ↓
syntax tree
   ↓
semantic analysis
   ↓
interpretation, transformation, or execution

Parsing shows why symbolic representation matters. A computational system must not only receive symbols. It must recognize their structure.

Back to top ↑

Regular and Context-Free Languages

Formal language theory classifies languages according to the kinds of rules and recognizers needed to define them. Two especially important classes are regular languages and context-free languages.

Regular languages can be recognized by finite automata and described by regular expressions. They are useful for tokenization, pattern matching, simple validation, and search. Context-free languages can describe nested structures and are often used for programming-language syntax, arithmetic expressions, markup, and parsed documents.

Regular expressions are powerful for certain tasks, but they are not suitable for every structured language. Nested structures often require grammars and parsers. A common computational mistake is trying to process a complex hierarchical language with a flat pattern-matching tool.

Back to top ↑

Symbolic Representation in Programming

Programming languages are formal languages with operational meaning. Their syntax defines valid programs. Their semantics defines how programs behave. Their type systems, module systems, runtimes, compilers, and interpreters determine how symbolic expressions become computation.

A program is not merely text. It is a structured symbolic artifact. Its characters become tokens. Its tokens become syntax trees. Its syntax trees become typed structures, intermediate representations, bytecode, machine code, or interpreted actions.

Symbolic representation also shapes how people think about programs. Names, indentation, syntax, modules, types, and comments influence whether code can be understood, reviewed, tested, and maintained.

Back to top ↑

Data Formats, Markup, and Schemas

Formal languages are not limited to programming languages. Data formats and markup languages are also formal or semi-formal systems for symbolic representation. They define how information is structured so that systems can exchange, validate, transform, and display it.

JSON, XML, HTML, CSV, YAML, RDF, SQL DDL, protocol buffers, and schema languages all represent information in structured symbolic form. The structure matters because downstream systems depend on it.

Schemas are especially important because they define constraints on symbolic representation. A schema can specify required fields, allowed values, nested structures, data types, relationships, and validation rules. Without schemas, downstream systems may interpret the same symbols differently.

Back to top ↑

Logic, Proof, and Symbolic Reasoning

Formal languages are central to logic and proof. A logical language defines valid formulas. A proof system defines valid transformations from premises to conclusions. A theorem prover, proof assistant, or model checker can then operate over symbolic structures.

This is one of the deepest links between symbolic representation and computation. A proof can be treated as a structured symbolic artifact. A program can be checked against a specification. A type system can prevent invalid expressions. A solver can search for assignments satisfying constraints. A model checker can explore possible states.

Symbolic reasoning depends on disciplined representation. If the language is unclear, the reasoning built on it becomes fragile.

Back to top ↑

Limits of Symbolic Representation

Symbolic representation is powerful, but it has limits. Not everything meaningful is easy to formalize. Human categories may be ambiguous. Institutional rules may conflict. Natural language may carry context, tone, implication, and history. Ethical judgment may not reduce cleanly to a grammar, schema, or predicate.

Formal representation always selects. It decides what symbols exist, what structures count, what distinctions matter, and what gets ignored. This makes symbolic representation both useful and risky. It can clarify, but it can also oversimplify.

Formal languages should not be treated as replacements for judgment. They are tools for making structure explicit so it can be processed, questioned, tested, and governed.

Back to top ↑

Back to top ↑

Mathematics, Computation, and Modeling

Formal languages can be described through alphabets, strings, grammars, and recognition functions.

An alphabet defines possible symbols:

The set of all finite strings over an alphabet is written:

A language is a subset of possible strings:

A grammar defines how valid strings are generated:

A recognizer can be represented as a function:

These ideas connect formal language theory to real computational tools: lexers, parsers, validators, compilers, interpreters, schemas, solvers, and proof systems.

Back to top ↑

Python Workflow: Formal Language Structure Audit

The Python workflow below creates a simple synthetic audit for symbolic representation cases. It scores alphabet clarity, grammar explicitness, syntax validation, semantic clarity, parser readiness, schema support, error reporting, testability, interoperability, and governance readiness.

# formal_language_audit.py
# Dependency-light workflow for evaluating formal-language and symbolic-representation quality.

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 FormalLanguageCase:
    case_name: str
    representation_context: str
    symbolic_structure: str
    alphabet_clarity: float
    grammar_explicitness: float
    syntax_validation: float
    semantic_clarity: float
    parser_readiness: float
    schema_support: float
    error_reporting: float
    testability: float
    interoperability: float
    governance_readiness: float


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


def representation_quality(case: FormalLanguageCase) -> float:
    return clamp(
        100.0 * (
            0.10 * case.alphabet_clarity
            + 0.12 * case.grammar_explicitness
            + 0.12 * case.syntax_validation
            + 0.12 * case.semantic_clarity
            + 0.10 * case.parser_readiness
            + 0.10 * case.schema_support
            + 0.10 * case.error_reporting
            + 0.08 * case.testability
            + 0.08 * case.interoperability
            + 0.08 * case.governance_readiness
        )
    )


def representation_risk(case: FormalLanguageCase) -> float:
    weak_points = [
        1.0 - case.alphabet_clarity,
        1.0 - case.grammar_explicitness,
        1.0 - case.syntax_validation,
        1.0 - case.semantic_clarity,
        1.0 - case.parser_readiness,
        1.0 - case.schema_support,
        1.0 - case.error_reporting,
        1.0 - case.interoperability,
    ]
    return clamp(100.0 * mean(weak_points))


def diagnose(quality: float, risk: float) -> str:
    if quality >= 80 and risk <= 25:
        return "strong symbolic representation with clear grammar, validation, and interpretation"
    if quality >= 65 and risk <= 40:
        return "usable symbolic representation with review needs"
    if risk >= 55:
        return "high representation risk; language, grammar, schema, or semantics may be unclear"
    return "partial symbolic representation; improve grammar, semantics, validation, or governance"


def build_cases() -> list[FormalLanguageCase]:
    return [
        FormalLanguageCase(
            case_name="Expression grammar",
            representation_context="Arithmetic expression evaluator.",
            symbolic_structure="Tokens, grammar rules, parse trees, and evaluation semantics.",
            alphabet_clarity=0.82,
            grammar_explicitness=0.86,
            syntax_validation=0.84,
            semantic_clarity=0.78,
            parser_readiness=0.82,
            schema_support=0.62,
            error_reporting=0.74,
            testability=0.82,
            interoperability=0.68,
            governance_readiness=0.64,
        ),
        FormalLanguageCase(
            case_name="JSON configuration schema",
            representation_context="Application configuration file.",
            symbolic_structure="Keys, values, nested objects, schema validation, and defaults.",
            alphabet_clarity=0.76,
            grammar_explicitness=0.78,
            syntax_validation=0.84,
            semantic_clarity=0.72,
            parser_readiness=0.80,
            schema_support=0.86,
            error_reporting=0.72,
            testability=0.78,
            interoperability=0.82,
            governance_readiness=0.70,
        ),
        FormalLanguageCase(
            case_name="SQL query layer",
            representation_context="Relational data retrieval workflow.",
            symbolic_structure="Query syntax, predicates, joins, constraints, and result schemas.",
            alphabet_clarity=0.74,
            grammar_explicitness=0.76,
            syntax_validation=0.78,
            semantic_clarity=0.70,
            parser_readiness=0.74,
            schema_support=0.82,
            error_reporting=0.68,
            testability=0.74,
            interoperability=0.78,
            governance_readiness=0.72,
        ),
        FormalLanguageCase(
            case_name="Rule-language workflow",
            representation_context="Institutional decision-routing rules.",
            symbolic_structure="If-then rules, predicates, exceptions, review states, and traceable outputs.",
            alphabet_clarity=0.70,
            grammar_explicitness=0.68,
            syntax_validation=0.66,
            semantic_clarity=0.64,
            parser_readiness=0.60,
            schema_support=0.70,
            error_reporting=0.66,
            testability=0.72,
            interoperability=0.62,
            governance_readiness=0.80,
        ),
    ]


def run_audit() -> list[dict[str, object]]:
    rows: list[dict[str, object]] = []
    for case in build_cases():
        quality = representation_quality(case)
        risk = representation_risk(case)
        rows.append({
            **asdict(case),
            "representation_quality": round(quality, 3),
            "representation_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_representation_quality": round(mean(float(row["representation_quality"]) for row in rows), 3),
        "average_representation_risk": round(mean(float(row["representation_risk"]) for row in rows), 3),
        "highest_quality_case": max(rows, key=lambda row: float(row["representation_quality"]))["case_name"],
        "highest_risk_case": max(rows, key=lambda row: float(row["representation_risk"]))["case_name"],
        "interpretation": "Symbolic representation quality depends on alphabet clarity, grammar explicitness, syntax validation, semantic clarity, parser readiness, schema support, error reporting, testability, interoperability, and governance."
    }


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

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

    print("Formal language structure audit complete.")
    print(TABLES / "formal_language_audit.csv")


if __name__ == "__main__":
    main()

This workflow treats symbolic representation as something that can be reviewed. It asks whether the language is well-defined enough to parse, validate, interpret, test, exchange, and govern.

Back to top ↑

R Workflow: Symbolic Representation Summary

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

# formal_language_summary.R
# Base R workflow for summarizing symbolic representation quality and 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, "formal_language_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_representation_quality = mean(data$representation_quality),
  average_representation_risk = mean(data$representation_risk),
  highest_quality_case = data$case_name[which.max(data$representation_quality)],
  highest_risk_case = data$case_name[which.max(data$representation_risk)]
)

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

comparison_matrix <- rbind(
  data$representation_quality,
  data$representation_risk
)

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

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

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

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

grid()
dev.off()

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

dimension_means <- colMeans(data[, c(
  "alphabet_clarity",
  "grammar_explicitness",
  "syntax_validation",
  "semantic_clarity",
  "parser_readiness",
  "schema_support",
  "error_reporting",
  "testability",
  "interoperability",
  "governance_readiness"
)]) * 100

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

grid()
dev.off()

print(summary_table)

This workflow helps compare symbolic representation systems across clarity, validation, semantics, schemas, interoperability, and governance.

Back to top ↑

GitHub Repository

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

articles/formal-languages-and-symbolic-representation/
├── python/
│   ├── formal_language_audit.py
│   ├── tokenization_examples.py
│   ├── grammar_parser_examples.py
│   ├── syntax_tree_examples.py
│   ├── schema_validation_examples.py
│   ├── calculators/
│   │   ├── representation_quality_calculator.py
│   │   └── grammar_risk_calculator.py
│   └── tests/
├── r/
│   ├── formal_language_summary.R
│   ├── symbolic_representation_visualization.R
│   └── grammar_quality_report.R
├── julia/
│   ├── grammar_simulation.jl
│   └── automata_examples.jl
├── sql/
│   ├── schema_formal_language_cases.sql
│   ├── schema_symbolic_representations.sql
│   └── formal_language_queries.sql
├── haskell/
│   ├── GrammarTypes.hs
│   ├── SymbolicRepresentation.hs
│   └── Main.hs
├── rust/
│   └── src/
├── go/
│   └── main.go
├── c/
│   └── formal_language_audit.c
├── cpp/
│   └── formal_language_audit.cpp
├── fortran/
│   └── representation_quality_model.f90
├── java/
│   └── src/main/java/org/contentcatalyst/algorithms/
├── typescript/
│   └── src/
├── prolog/
│   └── formal_language_rules.pl
├── racket/
│   └── grammar_interpreter.rkt
├── docs/
│   ├── methodology.md
│   ├── article-notes.md
│   ├── formal-languages-and-symbolic-representation.md
│   ├── governance-notes.md
│   └── responsible-use.md
├── data/
│   └── synthetic_formal_language_cases.csv
├── outputs/
│   ├── tables/
│   ├── figures/
│   ├── json/
│   ├── logs/
│   └── reports/
├── notebooks/
│   └── formal_languages_and_symbolic_representation_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 Working with Formal Languages

A practical method for working with formal languages begins by asking what needs to be represented, what symbols are allowed, how valid structures are built, how invalid structures are rejected, and how valid structures are interpreted.

This method applies to programming languages, domain-specific languages, schemas, data formats, markup systems, configuration files, rule languages, and computational knowledge systems.

Back to top ↑

Common Pitfalls

A common pitfall is treating symbolic representation as neutral. Representation choices decide what can be expressed, what must be omitted, what is easy to validate, what is hard to notice, and what downstream systems will assume. A schema, grammar, or symbolic language is never merely technical plumbing.

Another pitfall is confusing valid syntax with meaningful interpretation. A string may parse correctly while still being semantically wrong, misleading, incomplete, unsafe, or out of scope. Formal validity is not the same as responsible use.

Common pitfalls include:

• unclear alphabet: failing to define allowed symbols, tokens, encodings, or characters;
• implicit grammar: relying on examples instead of explicit rules;
• ambiguous syntax: allowing the same string to have multiple unintended structures;
• weak semantics: defining valid form without defining meaning;
• poor error reporting: rejecting input without useful diagnostics;
• schema drift: changing data structures without updating validators and documentation;
• overusing regular expressions: applying flat pattern tools to nested or context-sensitive structures;
• hidden assumptions: encoding domain judgments without documenting them;
• context loss: reducing rich meaning to symbols without review conditions;
• governance gaps: allowing symbolic systems to evolve without versioning, testing, or accountability.

The remedy is disciplined representation: define symbols, specify grammar, validate structure, explain meaning, test examples, document limits, and govern change.

Back to top ↑

Why Symbolic Representation Matters

Formal languages and symbolic representation matter because computation depends on structured symbols. Programs, queries, schemas, proofs, rules, protocols, markup, data files, and configuration systems are all symbolic artifacts. They become computationally useful because their structure can be recognized, checked, transformed, interpreted, and executed.

Formal languages make representation precise. Grammars make valid structure explicit. Parsers turn strings into trees. Schemas validate data. Type systems restrict invalid use. Logic languages support inference. Compilers and interpreters turn symbolic expressions into action.

But symbolic representation also requires judgment. Every formal language selects what matters, what counts, what can be expressed, and what remains outside the system. Used well, formal languages make computation more understandable, testable, interoperable, and governable. Used poorly, they hide assumptions behind technical form. Computational reasoning requires seeing both sides.

Back to top ↑

Related Articles

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

Further Reading

• Aho, A.V., Lam, M.S., Sethi, R. and Ullman, J.D. (2006) Compilers: Principles, Techniques, and Tools. 2nd edn. Boston, MA: Addison-Wesley. Publisher information available at: Pearson.
• Backus, J.W. (1959) ‘The syntax and semantics of the proposed international algebraic language of the Zurich ACM-GAMM Conference’, Proceedings of the International Conference on Information Processing. Available through ACM bibliographic records at: ACM Digital Library.
• Chomsky, N. (1956) ‘Three models for the description of language’, IRE Transactions on Information Theory, 2(3), pp. 113–124. Available at: IEEE Xplore.
• Chomsky, N. (1959) ‘On certain formal properties of grammars’, Information and Control, 2(2), pp. 137–167. Available at: ScienceDirect.
• Grune, D. and Jacobs, C.J.H. (2008) Parsing Techniques: A Practical Guide. 2nd edn. New York: Springer. Available at: SpringerLink.
• Hopcroft, J.E., Motwani, R. and Ullman, J.D. (2006) Introduction to Automata Theory, Languages, and Computation. 3rd edn. Boston, MA: Addison-Wesley. Publisher information available at: Pearson.
• Knuth, D.E. (1965) ‘On the translation of languages from left to right’, Information and Control, 8(6), pp. 607–639. Available at: ScienceDirect.
• Lewis, H.R. and Papadimitriou, C.H. (1998) Elements of the Theory of Computation. 2nd edn. Upper Saddle River, NJ: Prentice Hall. Publisher information available at: Pearson.
• Louden, K.C. and Lambert, K.A. (2011) Programming Languages: Principles and Practices. 3rd edn. Boston, MA: Cengage Learning. Publisher information available at: Cengage.
• Naur, P. et al. (1960) ‘Report on the algorithmic language ALGOL 60’, Communications of the ACM, 3(5), pp. 299–314. Available at: ACM Digital Library.
• Pierce, B.C. (2002) Types and Programming Languages. Cambridge, MA: MIT Press. Available at: MIT Press.
• Scott, M.L. (2015) Programming Language Pragmatics. 4th edn. Cambridge, MA: Morgan Kaufmann. Publisher information available at: Elsevier.
• Sipser, M. (2012) Introduction to the Theory of Computation. 3rd edn. Boston, MA: Cengage Learning. Author information available at: MIT Mathematics.
• Wirth, N. (1976) Algorithms + Data Structures = Programs. Englewood Cliffs, NJ: Prentice-Hall. Author archive available at: ETH Zürich.

References

• Aho, A.V., Lam, M.S., Sethi, R. and Ullman, J.D. (2006) Compilers: Principles, Techniques, and Tools. 2nd edn. Boston, MA: Addison-Wesley. Publisher information available at: https://www.pearson.com/en-us/subject-catalog/p/compilers-principles-techniques-and-tools/P200000003363.
• Backus, J.W. (1959) ‘The syntax and semantics of the proposed international algebraic language of the Zurich ACM-GAMM Conference’, Proceedings of the International Conference on Information Processing. Bibliographic records available through: https://dl.acm.org/.
• Chomsky, N. (1956) ‘Three models for the description of language’, IRE Transactions on Information Theory, 2(3), pp. 113–124. Available at: https://ieeexplore.ieee.org/document/1056813.
• Chomsky, N. (1959) ‘On certain formal properties of grammars’, Information and Control, 2(2), pp. 137–167. Available at: https://www.sciencedirect.com/science/article/pii/S0019995859903626.
• Grune, D. and Jacobs, C.J.H. (2008) Parsing Techniques: A Practical Guide. 2nd edn. New York: Springer. Available at: https://link.springer.com/book/10.1007/978-0-387-68954-8.
• Hopcroft, J.E., Motwani, R. and Ullman, J.D. (2006) Introduction to Automata Theory, Languages, and Computation. 3rd edn. Boston, MA: Addison-Wesley. Publisher information available at: https://www.pearson.com/en-us/subject-catalog/p/introduction-to-automata-theory-languages-and-computation/P200000003398.
• Knuth, D.E. (1965) ‘On the translation of languages from left to right’, Information and Control, 8(6), pp. 607–639. Available at: https://www.sciencedirect.com/science/article/pii/S0019995865904262.
• Lewis, H.R. and Papadimitriou, C.H. (1998) Elements of the Theory of Computation. 2nd edn. Upper Saddle River, NJ: Prentice Hall. Publisher information available at: https://www.pearson.com/en-us/subject-catalog/p/elements-of-the-theory-of-computation/P200000003430.
• Louden, K.C. and Lambert, K.A. (2011) Programming Languages: Principles and Practices. 3rd edn. Boston, MA: Cengage Learning. Publisher information available at: https://www.cengage.com/c/programming-languages-principles-and-practices-3e-louden/.
• Naur, P. et al. (1960) ‘Report on the algorithmic language ALGOL 60’, Communications of the ACM, 3(5), pp. 299–314. doi: 10.1145/367236.367262.
• Pierce, B.C. (2002) Types and Programming Languages. Cambridge, MA: MIT Press. Available at: https://mitpress.mit.edu/9780262162098/types-and-programming-languages/.
• Scott, M.L. (2015) Programming Language Pragmatics. 4th edn. Cambridge, MA: Morgan Kaufmann. Publisher information available at: https://www.elsevier.com/books/programming-language-pragmatics/scott/978-0-12-410409-9.
• 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.
• Wirth, N. (1976) Algorithms + Data Structures = Programs. Englewood Cliffs, NJ: Prentice-Hall. Author archive available at: https://people.inf.ethz.ch/wirth/.

Back to top ↑