Structured pseudocode for LLM-mediated work.
LMPL describes computations, workflows, and translation targets at the level an LLM can reliably understand and act on. It can specify code to be generated, procedures for an LLM to perform directly, or contracts for tool-mediated work.
Source (SAS, R, SPSS, ...)
-> lift: read source, write structured pseudocode
LMPL
-> inspect, add contracts, flag semantic gaps
-> lower: read LMPL, write target code
Target (Python, SQL, Kotlin, ...)
LMPL is consumed by a language model rather than a traditional runtime. The model may lower it to code, perform it through reasoning, execute it through tool calls, build helper artifacts, or use it as an inspection document.
This repo has one core thesis and several applications of that thesis. The directory layout keeps those concerns separate.
core/
language-reference.md The LMPL language definition
grammar.ebnf Formal grammar
semantics.md Formal semantics
architecture.md How core and extensions relate
examples.md Core worked examples
extensions/
profiles/ Domain vocabularies layered on core LMPL
translation-guides/ Standards and guides for language <-> LMPL translation
applications/
sas-to-python/ Concrete application of LMPL as a SAS -> Python pivot
agent-procedure/ Concrete application of LMPL as an LLM procedure
principles/
lmpl/ Positioning principles and testable theses
research/
competitive-landscape.md
competitive-landscape-response.md
Use core/ when you want to understand LMPL itself. Use extensions/ when you want to add vocabulary or translation knowledge without changing core. Use applications/ when you want to see the core thesis applied to a domain or translation path.
Use principles/ when you want the rationale, boundaries, and empirical claims behind the design.
Direct LLM translation from source to target clusters errors. The translator must simultaneously parse source semantics, understand target idioms, select libraries, and bridge abstraction gaps in one step.
LMPL breaks this into two smaller tasks. Lifting captures what the source code does as language-neutral structured pseudocode. Lowering expresses that pseudocode in the target's native patterns. The intermediate representation gives you a place to inspect business logic, add contracts, document semantic gaps, and verify intent before code is generated.
The same structured pseudocode is also useful when the LLM is not generating code at all. A skill, runbook, or agent workflow can use LMPL-style procedures to tell the model what to do: read files, verify preconditions, call tools, halt on failed gates, build temporary checkers, and report results.
When the implementation is probabilistic, contracts become the validation layer. require, ensure, invariant, and assert are not decoration; they catch translation errors.
require all values in patients.age are non-negative
ensure no_duplicates(result, key: patient_id)
invariant total_debits == total_credits for every journal entry
Contracts in LMPL become assertions in the generated code. They travel from model-consumable procedure to implementation.
The hardest translation bugs are semantic: the code runs but computes the wrong answer because languages disagree on meaning. LMPL makes these visible.
@semantic_change:
"SAS sorts missing values before all non-missing values.
pandas sorts NaN after all non-NaN values by default.
Use na_position='first' in sort_values()."
LMPL allows natural language inside structured pseudocode, for example filter(where: the customer has not been flagged for deletion). When the consumer is an LLM, this is a design feature rather than a parsing failure.
LMPL distinguishes missing from null. missing means a value should exist but was not observed, as in SAS . or R NA. null means absence by design, as in SQL NULL or Python None. This distinction is a common source of subtle migration bugs.
LMPL separates what is described from how the LLM should consume it:
specify— inspect or review intended behaviortranslate— generate a target artifactperform.internal— resolve directly through model reasoningperform.tool_call— act through available toolsperform.tool_build— build a helper artifact or tool before actingperform.auto— choose the least powerful sufficient performance strategyauto— choose the overall consumption mode from context
LMPL extends along two axes.
Translation Guides teach an LLM how to translate between a language and LMPL. Each Language Guide covers a language's relationship to LMPL in both directions. See extensions/translation-guides/standard.md.
Domain Profiles add domain-specific types, annotations, and semantic rules on top of core LMPL. Profiles add vocabulary; they do not replace the core language. See extensions/profiles/.
- Read core/language-reference.md for the language definition.
- Read core/architecture.md for the boundary between core, profiles, and translation guides.
- Read applications/sas-to-python/README.md for the current flagship application.
- Read applications/agent-procedure/README.md for LMPL-style pseudocode as an LLM-executed procedure.
- Read principles/lmpl/README.md for positioning principles and the semantic-compression thesis.
- Read research/competitive-landscape-response.md for the strategic framing.
LMPL is a v0.3 specification. The language is defined. The core thesis, that structured pseudocode improves LLM-mediated translation and procedure execution, is plausible but empirically unvalidated.
What exists:
- Complete language reference with formal grammar and semantics
- Five domain profiles: agentic, financial, infrastructure, ML, security
- Translation Guide standard
- Competitive landscape analysis
- SAS-to-Python worked application material
- Agent procedure worked application material
What's next:
- Extract the SAS Language Guide from existing specification material.
- Build an orchestration skill or MCP server for lift, validate, and lower.
- Run empirical validation against direct translation and plain natural-language summaries.
- Add a second Language Guide to test the compositional translation model.
TBD