Marsha: an LLM compiler that turns .mrsh specs into tested Python
Marsha is a functional, higher-level, English-based programming language that gets compiled into tested Python software by an LLM
At a glance
- What is it?
- Marsha is an MIT-licensed, alpha-stage language whose compiler prompts an LLM to emit Python, then validates that output against examples you write in the same file. It is a reasonable fit for small, well-exemplified data transformations and a poor fit for anything whose behaviour you cannot pin down with examples.
- Who is it for?
- Adopt Marsha for narrow, example-driven transformations where you can write the expected input and output pairs yourself and where the pandas dependency is acceptable. Do not adopt it for libraries that other code imports, for anything needing deterministic output across runs, or for logic you cannot express as concrete examples.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap Marsha tries to close between a prompt and a tested function
Asking a model for a data transformation usually produces code you have to read, run and repair by hand. Marsha's premise is that the repair step can be folded into the specification. You write a function signature, a prose description and a list of example calls with expected results in a .mrsh file. The compiler drives an LLM to produce Python, and those same examples become a test suite that the generated code must satisfy. The README describes this as a feedback loop that makes Marsha more reliable than using the LLM directly, and it draws the comparison to constraint-based programming: you verify behaviour inside the definition, but Marsha tolerates incomplete constraints where a constraint language would refuse to compile. That tolerance is the interesting design decision. It means the tool is usable when you only know a few cases, and it also means the compiler can succeed while leaving the ambiguous parts of your intent to the model's judgement. The target user is someone who can state a transformation in English and supply concrete input and output pairs, not someone who wants a general-purpose language.
How a .mrsh file is structured: types, declarations, prose, examples
A .mrsh file holds one or more function definitions, and the syntax borrows from Markdown. Data types are declared with a heading and a CSV-shaped body. The README shows a type EmployeeSkills with columns name and skill and rows such as Bob, math and Lisa, coding. A type can also be inferred from a CSV file by naming it after the heading, as in the example EmployeesByDepartment employees_by_department.csv. Functions have three parts. The declaration is a heading prefixed with func, followed by a single-word name, the input types in parentheses, and the output type after a colon. The types need not be classic software types; the README says they can be simple descriptions of what the type is meant to be. The description is ordinary prose explaining the transformation, and the README notes that being more explicit reduces variability in the generated output. The example section is a bullet list of calls with expected results, including cases that should throw an error. Marsha uses those examples both as extra context for the model and as the test suite that validates what comes back. The data flow is therefore spec in, prompt out, Python and tests back, with the examples acting as the acceptance gate.
Installing the compiler and running a file
The README gives two install paths. For a uv-based setup, the package installs straight from the repository and runs as a module: uv pip install git+https://github.com/alantech/marsha followed by python -m marsha data_mangling.mrsh. From a source checkout there is a make install target on Linux and macOS, and an install.bat on Windows. That target builds a virtualenv containing Marsha and places a launcher at ~/.local/bin/marsha, or ~/.local/bin/marsha.bat on Windows, which runs python -m marsha from that virtualenv and passes arguments through. The prefix is configurable: make install PREFIX=/usr/local, or install.bat C:\tools. The README also documents a MARSHA_VENV environment variable that overrides the virtualenv location for a single invocation, and make uninstall or uninstall.bat to remove the launcher. The README does not state which LLM provider the compiler contacts or which environment variables supply credentials, so that is the first thing to check before running a file. It also does not show where the generated Python or the generated tests are written, or whether they are kept for inspection.
The example list is the contract, and its limits are the tool's limits
Everything the compiler can verify comes from the examples you write. In the README's get_employee_skills sample, the list covers a call with no arguments that should throw, single-argument calls that should throw, empty lists, one-sided lists, and two cases where employees and departments are merged and unmatched entries are dropped. That is a careful set, and it is careful because a human wrote it. If your examples cover only the happy path, the generated Python is tested only on the happy path, and the README's claim about reliability weakens accordingly. The error cases matter more than they first appear: a function that should throw on missing arguments is a different function from one that returns an empty list, and the compiler has no way to know which you meant unless an example says so. The README also warns that the syntax is subject to change while Marsha is in alpha, which puts a maintenance cost on every .mrsh file you keep. A second limitation is the prose description. It is the one part of the specification that is not mechanically checked, so it is where ambiguity survives into the generated code.
Where Marsha is the wrong tool
Marsha compiles through a model, so two compilations of the same file are not guaranteed to produce identical Python. That rules it out for code whose output must be reproducible from a version-controlled artifact alone, and it complicates review, because a diff in the .mrsh file does not tell a reviewer what changed in the generated code. It is also a poor fit for anything that will be imported as a library by other Python code. The generated output is the artifact, not a stable API you control, and the README offers no guidance on pinning or freezing it. Long-lived services are another mismatch: the README describes Marsha as being in an alpha state and invites people with a legitimate use case to make contact, which reads as a project still finding its shape. Finally, if your transformation is already expressible in a few lines of pandas, the round trip through a description, an example list and a model call adds a dependency on an external service without removing much work.
How Marsha differs from asking a model for code in a chat window
The obvious alternative is prompting a model directly, pasting your sample data and expected output into the conversation and copying the Python back. The difference is not the model call, which both approaches make. It is that Marsha keeps the examples in the source file and turns them into tests that run automatically, so the check is repeatable rather than a one-off read-through. That also makes the failure mode different. With a chat window, a wrong result usually shows up when you run the code yourself; with Marsha, a wrong result should surface as a failing example, provided the example set is good enough to catch it. The trade is control. Direct prompting lets you iterate in seconds and inspect every intermediate step; Marsha's compiler is a black box between your .mrsh file and the Python it emits, and the README does not describe how to see the prompt it constructs or the response it receives. For a one-off script, the chat window is faster. For a transformation you will re-run and want to keep honest, the embedded test suite is the part that earns its keep.
Licence, maintenance and what an upgrade can cost you
Marsha is MIT-licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are preserved. That is permissive and carries no copyleft obligation on the Python you generate, though this is a description of the licence text and not legal advice. The maintenance picture is less settled. The repository has no releases retrieved, so there is nothing to pin to, and installation from the README points at the Git repository directly. The README states the syntax is subject to change while Marsha is in alpha, which means a change to the func heading format, the type declaration format or the example bullet syntax can invalidate files you already wrote, and there is no version number to hold fixed. Your real upgrade cost is therefore re-validating every .mrsh file after pulling a new commit, plus whatever the compiler depends on from the model provider. The install target does isolate dependencies in its own virtualenv, which limits the blast radius on the rest of your environment.
Editorial conclusion
Adopt Marsha for narrow, example-driven transformations where you can write the expected input and output pairs yourself and where the pandas dependency is acceptable. Do not adopt it for libraries that other code imports, for anything needing deterministic output across runs, or for logic you cannot express as concrete examples. Before committing, verify three things: how the compiler reaches an LLM and with which credentials, whether the generated Python and the test suite are written to disk where you can review them, and how a failing example is reported. The README calls the syntax subject to change while Marsha is in alpha, so treat any .mrsh file as something you may have to rewrite after an upgrade.
Community notes