Evaluation State Machines

Documentation status: architecture — see Maturity and evidence.

The FPLN engine uses a state-machine architecture to drive expression evaluation.

Execution table

Conceptually, the engine resolves an evaluation function from two coordinates:

(expression type, evaluation state) -> evaluation function

An expression can therefore resume at a different state after one of its dependencies has been evaluated.

Dynamic and local environments

The engine provides separate strategy ranges for dynamic and local evaluation environments. An expression family can share one protocol across both modes or register different behavior.

This is important when reasoning about why evaluation is more than a simple recursive AST visitor.

Specialized protocols

The engine supports several registration shapes:

• pre/post evaluation for simple two-phase expressions;
• application with additional phases for functional calls;
• push-down automata for forms requiring a structured third phase;
• pattern matching with explicitly indexed states;
• generic automata for families with their own state sequence.

Stacks and context

Evaluation uses a context that carries, among other things:

• an execution stack;
• a data stack;
• the current environment;
• the available conceptual graph;
• the current process when applicable;
• error and diagnostic state.

The automaton state and these stacks together form the resumption protocol.

Why this architecture matters

It supports:

1. composition across expression paradigms;
2. deferred evaluation;
3. partial application;
4. structured collection operations;
5. pattern matching;
6. precise diagnostics for in-flight evaluation;
7. engine evolution without turning every new expression into a global special case.

Public boundary

The mechanisms described here are architectural invariants. Internal class, table, and function identifiers may evolve and must not be used by applications.