Typed Model Records and Functional Workflows in Haskell

Last Updated June 16, 2026

Typed model records and functional workflows in Haskell help make mathematical models explicit, auditable, reusable, and harder to misuse. In systems modeling, a model is not only an equation or simulation. It is also a structured record of variables, parameters, units, assumptions, initial conditions, boundary conditions, solver settings, outputs, diagnostics, and interpretive limits.

Haskell is useful in this context because it encourages precise data types, pure functions, immutable values, explicit transformations, compositional design, and reproducible workflows. These features do not make a model correct by themselves, but they can make model structure easier to inspect and harder to blur.

This article introduces typed model records and functional workflows in Haskell for calculus-based systems modeling, including records, algebraic data types, pure functions, typed parameter sets, validated inputs, explicit units, solver configuration records, diagnostic outputs, reproducible exports, governance queues, and responsible interpretation.

Typed model records make modeling choices visible. Instead of passing loose values through a script, a workflow can define named records for parameters, states, observations, solver settings, assumptions, diagnostics, and outputs. This structure supports reproducibility because each result can be traced back to the records that generated it.

The central question is not only “Can Haskell compute the model?” It is “Can the workflow make the model’s structure, assumptions, transformations, diagnostics, and interpretive limits explicit enough to review?”

Why Typed Model Records Matter

Typed model records matter because complex modeling workflows often fail through ambiguity rather than arithmetic error. A parameter may lack units. A growth rate may be confused with a percentage. A solver tolerance may be omitted. A calibrated value may be reused outside its valid range. A simulation output may be separated from the assumptions that produced it.

A typed record does not solve every problem, but it requires the modeler to name and structure key parts of the workflow.

Typed records shift modeling from informal value-passing toward structured, reviewable computation.

Back to top ↑

What a Model Record Is

A model record is a structured representation of a model component. It can describe parameters, states, observations, solver settings, outputs, diagnostics, assumptions, or interpretation notes. In Haskell, records provide named fields that make these components explicit.

The record is not the model by itself. It is the structured container that keeps the model’s parts visible and connected.

Back to top ↑

Why Haskell Fits Model Governance

Haskell is not the most common language for applied modeling, but it offers useful design principles for serious computational work. Pure functions make transformations easier to reason about. Algebraic data types let workflows distinguish cases explicitly. Records make fields visible. Pattern matching forces the code to handle different model states. Immutability reduces accidental mutation.

The value is not that Haskell replaces Python, R, Julia, SQL, or compiled languages. The value is that typed functional design can strengthen the architecture of model records and reproducible workflows across the whole repository.

Back to top ↑

Records, Algebraic Data Types, and Domain Models

Algebraic data types let a workflow define precise categories. For example, a solver status can be explicitly represented as converged, failed, warning, or not evaluated. A model domain can distinguish teaching examples from calibrated models, benchmark cases, or governance review records.

data SolverStatus
  = Converged
  | Warning String
  | Failed String
  | NotEvaluated
  deriving (Show, Eq)

data ModelUse
  = TeachingExample
  | CalibrationStudy
  | ScenarioExploration
  | GovernanceReview
  deriving (Show, Eq)

These categories are more transparent than unstructured strings. They also make it harder for a workflow to ignore important cases.

Typed domain models are a way of saying: the workflow should know what kind of thing each value represents.

Back to top ↑

Pure Functions and Reproducible Transformations

A pure function has no hidden side effects. Given the same inputs, it returns the same output. In modeling workflows, pure functions are useful for equations, transformations, scoring rules, validation checks, and deterministic simulation steps.

stepLogistic :: Double -> ModelParameters -> ModelState -> ModelState
stepLogistic dt params state =
  let x = stock state
      r = growthRate params
      k = carryingCapacity params
      dx = r * x * (1 - x / k)
  in state { stock = x + dt * dx }

The function does not read hidden files, mutate global variables, or silently change configuration. That makes it easier to test, reuse, and review.

Pure functions help separate model logic from file handling, display code, and execution environment.

Back to top ↑

Typed Parameters, Units, and Validation

Parameter values should not float through a model without names, units, ranges, or validation rules. Typed records help prevent common mistakes by requiring parameters to be grouped and checked before the model is run.

data ModelParameters = ModelParameters
  { growthRate :: Double
  , carryingCapacity :: Double
  , initialStock :: Double
  , timeStep :: Double
  , horizon :: Double
  } deriving (Show, Eq)

validateParameters :: ModelParameters -> [String]
validateParameters params =
  concat
    [ if growthRate params <= 0 then ["growthRate must be positive"] else []
    , if carryingCapacity params <= 0 then ["carryingCapacity must be positive"] else []
    , if initialStock params <= 0 then ["initialStock must be positive"] else []
    , if timeStep params <= 0 then ["timeStep must be positive"] else []
    , if horizon params <= 0 then ["horizon must be positive"] else []
    ]

Validation does not prove that parameter values are empirically correct. It checks basic structural requirements so invalid values are not quietly accepted.

Validation is a governance layer. It is a check on workflow structure, not a substitute for calibration, evidence, or judgment.

Back to top ↑

Functional Workflows for Calculus Models

Calculus-based systems models often involve rates, integrals, derivatives, differential equations, optimization, and sensitivity analysis. Functional workflows can organize these components as a sequence of typed transformations.

The workflow becomes easier to audit because each transformation has a type, a purpose, and an output record.

Back to top ↑

Diagnostics, Governance, and Audit Trails

Typed workflows can help preserve diagnostics rather than letting them disappear into console output. A diagnostic record can include status, warnings, residuals, convergence flags, parameter validation messages, solver notes, and interpretation limits.

data DiagnosticRecord = DiagnosticRecord
  { diagnosticName :: String
  , diagnosticStatus :: SolverStatus
  , diagnosticMessage :: String
  , reviewRequired :: Bool
  } deriving (Show, Eq)

Governance records can then be generated from diagnostics. If a parameter fails validation, a solver reports instability, or a result depends on a fragile assumption, the workflow can create a review item rather than hiding the concern.

This is one of the strongest reasons to include Haskell in a multi-language modeling repository: it can help define disciplined records that other languages can export, read, or mirror.

Back to top ↑

Limits of Type Safety

Type safety is valuable, but it has limits. A type can ensure that a parameter is present, but it cannot prove the parameter is empirically correct. A validation function can reject negative stock values, but it cannot prove the model represents the real system. A pure function can be reproducible and still encode a poor assumption.

Typed workflows improve the discipline of representation. They do not replace scientific, mathematical, ethical, or institutional judgment.

Back to top ↑

Systems Modeling Interpretation

In systems modeling, typed records and functional workflows support interpretation by making the chain from assumption to output more visible. They help analysts see which parameters were used, which equations transformed them, which diagnostics were produced, which warnings were raised, and which claims depend on which conditions.

This matters especially when models are reused, extended, published, or connected to decision support. A single chart or trajectory may look persuasive, but without structured records it can be difficult to know which assumptions, units, solver settings, and parameter values produced it.

The stronger interpretive standard is not “the code ran.” It is: “the workflow preserved structured records for parameters, assumptions, transformations, diagnostics, outputs, and claim limits.”

Back to top ↑

Mathematical Deepening

This section adds a more formal layer for mathematically advanced readers. Typed model records and functional workflows in Haskell connect data modeling, type systems, algebraic data types, pure functions, deterministic transformations, function composition, validation logic, structured outputs, numerical diagnostics, parameter governance, and reproducible scientific computing.

Back to top ↑

Back to top ↑

Computation and Reproducible Workflows

Computational workflows for typed model records should preserve structured inputs, validation results, model transformations, solver settings, output records, diagnostics, review warnings, and export formats. Haskell can provide a disciplined typed layer while Python, R, SQL, Julia, and other languages support analysis, visualization, reporting, and database review.

The practical goal is not to make every model purely functional. The goal is to define clear records and transformations so that the modeling workflow becomes more transparent and easier to audit.

Back to top ↑

Haskell Workflow: Typed Model Records

The Haskell workflow below defines typed records for parameters, states, diagnostics, and model outputs. It validates parameters, simulates a simple logistic model, and exports reviewable output records.

module Main where

import Text.Printf (printf)

data SolverStatus
  = Converged
  | Warning String
  | Failed String
  | NotEvaluated
  deriving (Show, Eq)

data ModelUse
  = TeachingExample
  | CalibrationStudy
  | ScenarioExploration
  | GovernanceReview
  deriving (Show, Eq)

data ModelParameters = ModelParameters
  { growthRate :: Double
  , carryingCapacity :: Double
  , initialStock :: Double
  , timeStep :: Double
  , horizon :: Double
  , parameterNote :: String
  } deriving (Show, Eq)

data ModelState = ModelState
  { modelTime :: Double
  , stock :: Double
  } deriving (Show, Eq)

data DiagnosticRecord = DiagnosticRecord
  { diagnosticName :: String
  , diagnosticStatus :: SolverStatus
  , diagnosticMessage :: String
  , reviewRequired :: Bool
  } deriving (Show, Eq)

data ModelOutput = ModelOutput
  { outputUse :: ModelUse
  , outputParameters :: ModelParameters
  , finalState :: ModelState
  , diagnostics :: [DiagnosticRecord]
  , interpretationWarning :: String
  } deriving (Show, Eq)

validateParameters :: ModelParameters -> [String]
validateParameters params =
  concat
    [ if growthRate params <= 0 then ["growthRate must be positive"] else []
    , if carryingCapacity params <= 0 then ["carryingCapacity must be positive"] else []
    , if initialStock params <= 0 then ["initialStock must be positive"] else []
    , if timeStep params <= 0 then ["timeStep must be positive"] else []
    , if horizon params <= 0 then ["horizon must be positive"] else []
    ]

stepLogistic :: ModelParameters -> ModelState -> ModelState
stepLogistic params state =
  let x = stock state
      r = growthRate params
      k = carryingCapacity params
      dt = timeStep params
      dx = r * x * (1 - x / k)
  in ModelState
      { modelTime = modelTime state + dt
      , stock = x + dt * dx
      }

simulate :: ModelParameters -> [ModelState]
simulate params =
  takeWhile
    (\state -> modelTime state <= horizon params + 1.0e-9)
    (iterate (stepLogistic params) initial)
  where
    initial = ModelState 0.0 (initialStock params)

buildDiagnostics :: ModelParameters -> [String] -> [ModelState] -> [DiagnosticRecord]
buildDiagnostics params validationMessages states =
  let final = last states
      validationDiagnostic =
        if null validationMessages
          then DiagnosticRecord "parameter_validation" Converged "All basic parameter checks passed." False
          else DiagnosticRecord "parameter_validation" (Warning (unwords validationMessages)) "Parameter validation requires review." True
      capacityDiagnostic =
        if stock final <= carryingCapacity params
          then DiagnosticRecord "capacity_check" Converged "Final stock remains within carrying capacity." False
          else DiagnosticRecord "capacity_check" (Warning "Final stock exceeds carrying capacity.") "Capacity interpretation requires review." True
  in [validationDiagnostic, capacityDiagnostic]

buildOutput :: ModelParameters -> ModelOutput
buildOutput params =
  let states = simulate params
      validationMessages = validateParameters params
      diagnosticRecords = buildDiagnostics params validationMessages states
  in ModelOutput
      { outputUse = GovernanceReview
      , outputParameters = params
      , finalState = last states
      , diagnostics = diagnosticRecords
      , interpretationWarning = "Typed records improve structural review but do not prove empirical validity."
      }

csvHeader :: String
csvHeader = "model_use,growth_rate,carrying_capacity,initial_stock,time_step,horizon,final_time,final_stock,warning"

csvRow :: ModelOutput -> String
csvRow output =
  let params = outputParameters output
      final = finalState output
  in printf "%s,%.6f,%.6f,%.6f,%.6f,%.6f,%.6f,%.6f,%s"
      (show (outputUse output))
      (growthRate params)
      (carryingCapacity params)
      (initialStock params)
      (timeStep params)
      (horizon params)
      (modelTime final)
      (stock final)
      (interpretationWarning output)

main :: IO ()
main = do
  let params =
        ModelParameters
          { growthRate = 0.35
          , carryingCapacity = 100.0
          , initialStock = 10.0
          , timeStep = 0.25
          , horizon = 20.0
          , parameterNote = "Synthetic teaching example for typed model governance."
          }

  let output = buildOutput params

  putStrLn csvHeader
  putStrLn (csvRow output)
  putStrLn ""
  putStrLn "Diagnostics:"
  mapM_ print (diagnostics output)

This workflow keeps parameters, state updates, diagnostics, and interpretation warnings attached to the output.

Back to top ↑

Python Workflow: Exporting a Comparable Model Record

The Python workflow below mirrors the typed-record idea with dataclasses and exports CSV, JSON, and Markdown governance outputs.

from __future__ import annotations

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


@dataclass(frozen=True)
class ModelParameters:
    growth_rate: float
    carrying_capacity: float
    initial_stock: float
    time_step: float
    horizon: float
    parameter_note: str


@dataclass(frozen=True)
class ModelState:
    model_time: float
    stock: float


@dataclass(frozen=True)
class DiagnosticRecord:
    diagnostic_name: str
    diagnostic_status: str
    diagnostic_message: str
    review_required: bool


@dataclass(frozen=True)
class ModelOutput:
    model_use: str
    parameters: ModelParameters
    final_state: ModelState
    diagnostics: list[DiagnosticRecord]
    interpretation_warning: str


def validate_parameters(params: ModelParameters) -> list[str]:
    messages: list[str] = []

    if params.growth_rate <= 0:
        messages.append("growth_rate must be positive")
    if params.carrying_capacity <= 0:
        messages.append("carrying_capacity must be positive")
    if params.initial_stock <= 0:
        messages.append("initial_stock must be positive")
    if params.time_step <= 0:
        messages.append("time_step must be positive")
    if params.horizon <= 0:
        messages.append("horizon must be positive")

    return messages


def step_logistic(params: ModelParameters, state: ModelState) -> ModelState:
    x = state.stock
    dx = params.growth_rate * x * (1 - x / params.carrying_capacity)

    return ModelState(
        model_time=state.model_time + params.time_step,
        stock=x + params.time_step * dx
    )


def simulate(params: ModelParameters) -> list[ModelState]:
    states = [ModelState(0.0, params.initial_stock)]

    while states[-1].model_time < params.horizon:
        states.append(step_logistic(params, states[-1]))

    return states


def build_output(params: ModelParameters) -> ModelOutput:
    validation_messages = validate_parameters(params)
    states = simulate(params)
    final = states[-1]

    diagnostics = [
        DiagnosticRecord(
            diagnostic_name="parameter_validation",
            diagnostic_status="converged" if not validation_messages else "warning",
            diagnostic_message="All basic parameter checks passed." if not validation_messages else "; ".join(validation_messages),
            review_required=bool(validation_messages)
        ),
        DiagnosticRecord(
            diagnostic_name="capacity_check",
            diagnostic_status="converged" if final.stock <= params.carrying_capacity else "warning",
            diagnostic_message="Final stock remains within carrying capacity." if final.stock <= params.carrying_capacity else "Final stock exceeds carrying capacity.",
            review_required=final.stock > params.carrying_capacity
        )
    ]

    return ModelOutput(
        model_use="governance_review",
        parameters=params,
        final_state=final,
        diagnostics=diagnostics,
        interpretation_warning="Typed records improve structural review but do not prove empirical validity."
    )


params = ModelParameters(
    growth_rate=0.35,
    carrying_capacity=100.0,
    initial_stock=10.0,
    time_step=0.25,
    horizon=20.0,
    parameter_note="Synthetic teaching example for typed model governance."
)

output = build_output(params)

output_dir = Path("outputs")
(output_dir / "tables").mkdir(parents=True, exist_ok=True)
(output_dir / "json").mkdir(parents=True, exist_ok=True)
(output_dir / "reports").mkdir(parents=True, exist_ok=True)

summary_row = {
    "model_use": output.model_use,
    "growth_rate": output.parameters.growth_rate,
    "carrying_capacity": output.parameters.carrying_capacity,
    "initial_stock": output.parameters.initial_stock,
    "time_step": output.parameters.time_step,
    "horizon": output.parameters.horizon,
    "final_time": output.final_state.model_time,
    "final_stock": output.final_state.stock,
    "interpretation_warning": output.interpretation_warning
}

with (output_dir / "tables" / "typed_model_output.csv").open("w", newline="", encoding="utf-8") as handle:
    writer = csv.DictWriter(handle, fieldnames=summary_row.keys())
    writer.writeheader()
    writer.writerow(summary_row)

with (output_dir / "tables" / "diagnostics.csv").open("w", newline="", encoding="utf-8") as handle:
    writer = csv.DictWriter(handle, fieldnames=asdict(output.diagnostics[0]).keys())
    writer.writeheader()
    for diagnostic in output.diagnostics:
        writer.writerow(asdict(diagnostic))

(output_dir / "json" / "typed_model_output.json").write_text(
    json.dumps(asdict(output), indent=2),
    encoding="utf-8"
)

report_lines = [
    "# Typed Model Record Audit",
    "",
    f"Model use: {output.model_use}",
    f"Final stock: {output.final_state.stock:.6f}",
    "",
    "## Diagnostics"
]

for diagnostic in output.diagnostics:
    report_lines.append(
        f"- **{diagnostic.diagnostic_name}** ({diagnostic.diagnostic_status}): {diagnostic.diagnostic_message}"
    )

report_lines.append("")
report_lines.append(output.interpretation_warning)

(output_dir / "reports" / "typed_model_record_audit.md").write_text(
    "\n".join(report_lines) + "\n",
    encoding="utf-8"
)

print("Wrote typed model record outputs.")

This workflow mirrors Haskell’s typed-record discipline while producing familiar CSV, JSON, and Markdown artifacts.

Back to top ↑

R Workflow: Reading Typed Record Outputs

The R workflow below reads the exported model and diagnostic tables, then creates a compact review summary.

model_output_path <- "outputs/tables/typed_model_output.csv"
diagnostics_path <- "outputs/tables/diagnostics.csv"

if (!file.exists(model_output_path) || !file.exists(diagnostics_path)) {
  stop("Run the Python or Haskell export workflow before reading typed model outputs.")
}

model_output <- read.csv(model_output_path)
diagnostics <- read.csv(diagnostics_path)

review_summary <- data.frame(
  model_use = model_output$model_use,
  final_time = model_output$final_time,
  final_stock = model_output$final_stock,
  diagnostic_count = nrow(diagnostics),
  review_required_count = sum(diagnostics$review_required == TRUE),
  interpretation_warning = model_output$interpretation_warning
)

dir.create("outputs/tables", recursive = TRUE, showWarnings = FALSE)

write.csv(
  review_summary,
  "outputs/tables/r_typed_model_review_summary.csv",
  row.names = FALSE
)

print(review_summary)
print(diagnostics)

This workflow shows how typed records can move across languages while preserving review fields and diagnostic status.

Back to top ↑

SQL Workflow: Model Record Governance Registry

SQL can document typed model concepts, governance roles, and review warnings for repository-level audit trails.

CREATE TABLE typed_model_record_registry (
    record_key TEXT PRIMARY KEY,
    record_name TEXT NOT NULL,
    computational_role TEXT NOT NULL,
    systems_modeling_role TEXT NOT NULL,
    review_warning TEXT NOT NULL
);

INSERT INTO typed_model_record_registry VALUES
(
  'parameter_record',
  'Parameter record',
  'Stores named parameters, units, ranges, and source notes.',
  'Keeps model behavior tied to explicit assumptions.',
  'Typed parameters do not prove empirical correctness.'
);

INSERT INTO typed_model_record_registry VALUES
(
  'state_record',
  'State record',
  'Stores model state at a time or location.',
  'Supports reproducible trajectory and stock-flow review.',
  'State records should preserve units and time scale.'
);

INSERT INTO typed_model_record_registry VALUES
(
  'solver_record',
  'Solver record',
  'Stores method, time step, tolerance, horizon, and status.',
  'Connects numerical outputs to computational configuration.',
  'Solver settings can change model results and should not be hidden.'
);

INSERT INTO typed_model_record_registry VALUES
(
  'diagnostic_record',
  'Diagnostic record',
  'Stores warnings, convergence status, residuals, and review flags.',
  'Keeps reliability evidence attached to outputs.',
  'Diagnostics should be reviewed before interpretation.'
);

INSERT INTO typed_model_record_registry VALUES
(
  'assumption_record',
  'Assumption record',
  'Stores modeling assumptions and validity notes.',
  'Connects outputs to scope and interpretive boundaries.',
  'Assumptions should not be buried in prose alone.'
);

INSERT INTO typed_model_record_registry VALUES
(
  'claim_boundary',
  'Claim boundary',
  'Stores limits on what a model output can support.',
  'Separates computation from responsible public interpretation.',
  'Type safety does not replace human judgment.'
);

SELECT
    record_name,
    computational_role,
    systems_modeling_role,
    review_warning
FROM typed_model_record_registry
ORDER BY record_key;

This registry connects typed records to parameter governance, solver review, diagnostics, assumptions, and claim boundaries.

Back to top ↑

GitHub Repository

The companion repository for this article is designed as a reproducible mathematical-modeling workspace. It supports Haskell typed records, algebraic data types, pure functions, validation checks, solver-status records, model-output records, diagnostic records, CSV/JSON/Markdown exports, SQL governance tables, advanced audit logic, and reusable calculator scripts.

Back to top ↑

Interpretive Limits and Responsible Use

Typed model records and functional workflows improve structure, reproducibility, and auditability, but they do not prove that a model is correct. A clean type system can still encode a poor assumption. A pure function can still represent the wrong mechanism. A validation rule can reject impossible inputs while accepting plausible but unsupported values.

Responsible use requires documentation and review. Preserve parameter definitions, units, sources, validation rules, solver settings, diagnostics, warnings, assumptions, export formats, and claim boundaries. Use Haskell’s type discipline to make model structure explicit, not to imply certainty.

The central question is not only “Is the workflow typed?” It is “Do the types help preserve the evidence, assumptions, diagnostics, and limits needed for responsible interpretation?”

Back to top ↑

Related Articles

• Calculus for Systems Modeling
• Model Calibration Using Calculus-Based Methods
• Reproducible Calculus Workflows in R Markdown, Jupyter, and Multi-Language Repositories
• Scientific Computing for Systems Modeling
• Symbolic Calculus and Model Inspection
• Ordinary Differential Equation Solver Workflows
• Parameter Sweeps and Sensitivity Analysis
• Interpretation, Assumptions, and Responsible Mathematical Modeling
• Model Governance and Accountability
• Mathematical Modeling

Back to top ↑

Further Reading

• Bird, R. (2015) Thinking Functionally with Haskell. Cambridge: Cambridge University Press.
• Hutton, G. (2016) Programming in Haskell. 2nd edn. Cambridge: Cambridge University Press.
• Lipovača, M. (2011) Learn You a Haskell for Great Good! San Francisco, CA: No Starch Press.
• Marlow, S. (ed.) (2010) Haskell 2010 Language Report. Available from the Haskell community.
• Marlow, S. (2013) Parallel and Concurrent Programming in Haskell. Sebastopol, CA: O’Reilly Media.
• O’Sullivan, B., Goerzen, J. and Stewart, D. (2008) Real World Haskell. Sebastopol, CA: O’Reilly Media.
• Peyton Jones, S. (2003) Haskell 98 Language and Libraries: The Revised Report. Cambridge: Cambridge University Press.
• Thompson, S. (2011) Haskell: The Craft of Functional Programming. 3rd edn. Harlow: Addison-Wesley.
• Wadler, P. (1992) ‘The essence of functional programming’, Proceedings of the 19th ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages, pp. 1–14.
• Winskel, G. (1993) The Formal Semantics of Programming Languages: An Introduction. Cambridge, MA: MIT Press.

Back to top ↑

References

• Bird, R. (2015) Thinking Functionally with Haskell. Cambridge: Cambridge University Press.
• Hutton, G. (2016) Programming in Haskell. 2nd edn. Cambridge: Cambridge University Press.
• Lipovača, M. (2011) Learn You a Haskell for Great Good! San Francisco, CA: No Starch Press.
• Marlow, S. (ed.) (2010) Haskell 2010 Language Report. Available from the Haskell community.
• Marlow, S. (2013) Parallel and Concurrent Programming in Haskell. Sebastopol, CA: O’Reilly Media.
• O’Sullivan, B., Goerzen, J. and Stewart, D. (2008) Real World Haskell. Sebastopol, CA: O’Reilly Media.
• Peyton Jones, S. (2003) Haskell 98 Language and Libraries: The Revised Report. Cambridge: Cambridge University Press.
• Thompson, S. (2011) Haskell: The Craft of Functional Programming. 3rd edn. Harlow: Addison-Wesley.
• Wadler, P. (1992) ‘The essence of functional programming’, Proceedings of the 19th ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages, pp. 1–14.
• Winskel, G. (1993) The Formal Semantics of Programming Languages: An Introduction. Cambridge, MA: MIT Press.

Back to top ↑