1. Mathematical Structure of the DDSL as Bellman-Backus-Euler Calculus¶

This section fixes language for talking about the declarative layer of the DDSL. It does not fix how declarative syntax is executed to form an abstract syntax tree (AST) or any concrete computational implementation; concrete computational representation is left to the host language and libraries. It also does not yet fix the AST parsing of the top-level DDSL syntax.

Following Backus, we distinguish:

an object level (primitive strings, numerical objects, primitive functions, method declarations, etc.),
a function level (DDSL functions over those objects), and
a functional level (operators that take DDSL functions and return new functions).

1.1 Universes and Spaces¶

The DDSL consists of the following universes.

I. Objects¶

$\mathbb{O}$: a space of objects
Encompasses symbols, strings, valid numerical atoms/values, all function names, method names, etc.
The universal set containing all entities that can appear in DDSL syntax.
$\mathbb{O}_P \subset \mathbb{O}$: the space of primitive DDSL-native objects

These are the atomic building blocks of the language in the Backus sense (primitive values and primitive function symbols). They include:

Numeric atoms: real numbers, integers
Logical atoms: booleans
Mathematical object symbols: $\mathbb{R}$, $\mathbb{R}_+$, $\mathbb{Z}$, interval constructors, distribution families (e.g. Interval, Normal)
Primitive function symbols (Backus "objects"):
- Decorators with native meaning: @def, @in, @mapsto, @via, @constructed, …
- Primitive mathematical functions: sin, cos, exp, etc.
- Primitive operators: E (expectation), argmax, argmin, etc.
- Primitive method/constructor names: !linspace, !gauss-hermite, !brentq, !linear, …
- Core mathematical syntax tokens treated as primitive function symbols: +, -, *, /, ~, (and, where needed, : or @mapsto) — their exact roles are fixed by the syntactic rules that map them into the mathematical layer.

The set $\mathbb{O}_P$ is closed under: - finite union - finite intersection - finite Cartesian product - finite tuples and records

We will produce a complete, explicit list of these primitives in the final syntax directives.

$\mathbb{F} \subset \mathbb{O}$: a space of function objects
A function object is a well-formed DDSL function: a finite sequence of symbols from $\mathbb{O}_P$ that satisfies the DDSL grammar and denotes a function at the mathematical layer.
Function objects act (semantically) on primitive numerical objects and return objects. Syntactically they are built from primitive objects (including method/constructor symbols).
This is what actually appears in YAML model files.

Example:

g_av: [xa, w] @mapsto xv @via |
  xv = xa * r + w

A function object may be:
- given (e.g. an input value function to a stage), or
- produced as the output of a functional operator (e.g. a value function returned by a Bellman mover).
$\mathbb{T} \subset \mathbb{O}$: a space of functional operators
Syntactic higher-order function objects that take one or more functions in $\mathbb{F}$ as arguments and return functions in $\mathbb{F}$ as results.
Examples in DDSL syntax: Bellman operators, value-update operators, expectation operators, movers, etc.

The above definition lets us work at two levels: - At the function level, a discrete DP problem can be represented as a function $T : \mathbb{V} \to \mathbb{V}$ on a space of value-function representations. - At the functional level, the same object can be seen as a composition of named operators (movers, expectations, argmax blocks), which is the viewpoint we use for factorization and modularity.

A central design goal of the DDSL is to let function objects and functional operators be represented implicitly but exactly by the sequence of mathematical steps spelled out in the syntax, in a way that: - maps directly to the underlying mathematics; and - avoids relying on hidden state changes in variables (e.g. "primes" or ad hoc time-indexing tricks).

Functional operators are the key to stage composition and modularity: they make it possible to treat entire perches/stages as named, immutable building blocks in both the mathematical and computational layers.

II. Symbols as a kind of function object¶

IMPORTANT: In the Backus spirit, every declared name in the DDSL (outside of bound-variable positions) is interpreted as a function object.

A declaration like Xa @def R+ means: Xa is a nullary function whose mathematical meaning under Υ is “the space we call $\mathbb{R}_+$”.
A declaration like β @in (0,1) means: β is a nullary function whose value lies in the open interval $(0,1)$; after calibration, the calibration functor supplies the concrete numerical value. Thus $\mathbb{C}(\beta) = 0.96$.
A function definition
```
g_av: [xa, w] @mapsto xv @via |
  xv = xa * r + w
```
is a non-nullary function object with type judgment $\vdash g_{\text{av}} : X_a \times W \to X_v$ in the definitional system $\mathbb{D}$.

Bound variables like xa, xv, w, a are not objects in this sense: they are purely syntactic binders that disappear under the representation map $\rho$ (they become host-language parameters). Typing constraints such as xa @in Xa live in $\mathbb{D}$ as part of the type system and ensure, for example, that a composition g ∘ h is only well-formed when the codomain of h matches the domain of g. We use “type” here in this functional sense (domains/codomains of mathematical functions), not as a low-level machine data type.

III. Representational Universes¶

These are separate from objects.

$\mathbb{F}^{\text{COMP}}$: A space of computational functional representations
Canonical, AST-like objects representing host-language functions
Isomorphic to equivalence classes of host-language function definitions
Abstracts away trivial syntax variations (whitespace, comments, variable renaming)
$\mathbb{D}$: A definitional system
Grammar rules that assign mathematical meaning to well-formed syntax expressions
Governs how DDSL constructs are interpreted
Links syntax to semantics

IV. Mathematical Dynamic Programming Universe¶

Separate from representational universes and objects, this is the Platonic math layer.

$\mathbb{D}$: The definitional system of the DDSL. It consists of:
A typing discipline that decides which sequences of primitive objects form well-typed function objects in $\mathbb{F}$ (e.g., it knows that @mapsto expects a domain and codomain, that compositions must match domains/codomains, etc.).
A mathematical meaning map $\Upsilon : \mathbb{F} \to \mathbb{DM}$ that sends each well-typed function object to its corresponding mathematical operator (Bellman operator, transition kernel, policy function, etc.).

The computational representation map $$\rho : \mathbb{F}_{\text{calibrated, methodized}} \to \mathbb{F}^{\text{COMP}}$$ is not part of $\mathbb{D}$; it is an additional, implementation-level layer that turns well-typed, calibrated DDSL expressions into concrete host-language code (ASTs, functions, etc.).

$\mathbb{DM}$: We can also define a space $\mathbb{DM}$ as consisting of the set of all mathematical objects that can be represented in the DDSL — this is the space of Bellman operators and associated mathematical (set-theoretic?) statements.
$\mathbb{DM}$ consists of the space of operators (Bellman, integration, push-forward, and optimization operators) s.t. each stage is identified by a Bellman operator $\mathbb{T}$ (pull-back) and its push-forward operator $\mathbb{T}^*$ (push-forward) and can be decomposed into a sequence of operators (movers) that implement the Bellman decomposition.

1.2 Layer Architecture¶

Given the universes above, DDSL operates through three distinct but interconnected layers:

Syntactic Layer (YAML/DDSL)¶

What it is: The human-readable model specification syntax
Lives in: $\mathbb{F}\cup\mathbb{T}$ (function objects and functional operators)
Purpose: Declarative model definition
Example: YAML files with @mapsto, @via, @def syntax

IMPORTANT: Declared symbols in the model are formally considered as function objects. An annotation arvl_state: x @in X is function $f$ whose meaning $\mu f = \{x \in X\}$ is mathematical statement in $\mathbb{DM}$ -- typing constraint asserting that the argument x must lie in the space X. g : x @\mapsto y, then it is implied that the domain of f is X. In particular, $\mathbb{D}$ specifies that the composition $g\circ h$ is valid in the DDSL iff the codomain of $h$ is the domain of $g$. Importantly, we view the "typing view" not in the computational data-type sense, but in the sense that domains of functions are exactly specified (both the approximate and true domain) s.t. the composition of operations is well-defined.

Mathematical Layer (Platonic)¶

What it is: The abstract mathematical interpretation
Lives in: $\mathbb{DM}$ (dynamic-model operators)
Purpose: Theoretical understanding and guarantees
Example: Bellman operators, fixed-point theorems, convergence properties

Computational Layer (Executable)¶

What it is: The concrete implementation in host language, isomorphic to the AST of the DDSL
Lives in: $\mathbb{F}^{\text{COMP}}$ (computational representations)
Purpose: Actual numerical computation
Example: Python/Julia functions, NumPy arrays, solver routines

Mappings Between Layers¶

Two locally invertible (?TODO-AAS) maps connect these layers:

Mathematical Meaning Map ($\Upsilon$):
From: Syntax (in $\mathbb{F}\cup \mathbb{T}$)
To: Bellman operators (in $\mathbb{DM}$)
Purpose: Provides mathematical interpretation for human understanding and theoretical analysis
Nature: Platonic – describes what the model means mathematically
Computational Representation Map ($\rho$):
From: Calibrated and methodized syntax (in $\mathbb{F}\cup \mathbb{T}$)
To: Executable code (in $\mathbb{F}^{\text{COMP}}$)
Purpose: Generates runnable code for numerical computation
Nature: Constructive – produces what the computer actually executes

1.3 DDSL as Bellman-Backus-Euler Calculus¶

Let's link the structure above back to the higher-order goals of the DDSL. The DDSL explicitly supports functional programming in a way that maps directly to the exact mathematical statements of Bellman problems:

DDSL stages and movers describe operations that take functions as arguments and return functions as results.

The reason is to allow modularity while at the same time maintaining a one-to-one map between the "mathematical model" and the "computational model".

This higher-order structure enables: - Modular composition of economic models - Clean factorization of Bellman operators - Reusable stage and period components - Algebraic reasoning about program transformations

Separation of Concerns¶

The layer architecture enforces clean separation:

Declarative vs. Imperative: The syntactic layer declares what to compute, not how
Mathematical vs. Numerical: The mathematical layer provides theory; the computational layer provides algorithms
Abstract vs. Concrete: Function objects are abstract specifications; computational representations are concrete implementations

This three-layer architecture ensures that: 1. Models are human-readable and mathematically precise 2. The same model can have multiple computational implementations 3. Mathematical properties are preserved in computation (up to numerical approximation) 4. Modularity and composability are maintained throughout

Re-framing the symbol-syntax-function link: All denotable entities in the DDSL (outside of bound variables) are functions in the FP sense: possibly nullary (constants, spaces, parameters, constructors), or higher-order (movers, Bellman operators, expectation operators). Types are judgments about those functions, not first-class values. Bound variables are purely syntactic artifacts. That’s very close to Backus’ own setup, just adapted to your Bellman/DDSL context.