Pragmatic Separation of Intent

Representation vs. Intent

In traditional programming, syntax is tied to execution. An SQL SELECT statement is always a query. A Python assert is always a check.

CNL-PL operates on a different theory: The text describes a state of the world. What we do with that description is a separate layer called Pragmatics.

Consider the phrase: "The container is secure."

This is a representation of a fact. Depending on the pragmatic mode ("command") wrapping it, the meaning changes entirely:

• Query Mode: Is the container secure right now? (Read operation)
• Assert Mode: Update the database to mark the container as secure. (Write operation)
• Constraint Mode: Ensure the container is always secure. (Invariant definition)
• Plan Mode: Perform necessary actions (like encryption) to make the container secure. (Goal definition)

The Unified Frontend

The theoretical benefit of this separation is that users only need to learn one way to describe the world. They don't need a separate "Query Language", "Constraint Language", and "Planning Language". They learn the SVO structure and boolean logic once, and apply it everywhere.

This unification extends to the internal architecture. The compiler produces the same Intermediate Representation (Plan IR) regardless of the pragmatic. A SetPlan describing "secure containers" is identical whether it's being used to filter a list or to validate a compliance rule.

Engines as Backends

Pragmatics effectively act as "drivers" for different execution engines.

The Solver Engine treats the AST as a set of logical constraints (SAT/SMT) and tries to find variable assignments. The Planner Engine treats the AST as a goal state and searches the action space. The Proof Engine treats the AST as a theorem and searches the deduction space.

This modularity makes CNL-PL extensible. New pragmatics (e.g., "Optimize" or "Simulate") can be added by implementing new backends that consume the standard Plan IR, without changing the core language syntax.