Most programming languages pick a lane. TXR, a project that started in 2009, refuses to. It ships two languages in one binary: a pattern-matching language for scraping structured data out of messy text, and a Lisp dialect for processing that data once you have it. The reference manual runs over 900 pages. The executable is 1.7 megabytes.
Two Languages, One Problem Domain
The TXR Pattern Language handles the first mile of data work: getting information out of text that does not want to be parsed. Think bank statements converted to plain text by pdftotext, log files with inconsistent formatting, or CSV-like data where the delimiters shift between sections. Awk handles delimited records well enough, but Awk breaks down when the structure changes partway through a file or when the data is loosely organized rather than rigidly tabular.
TXR's pattern language takes a different approach. Instead of imperative statements, you write pattern-matching directives. Each directive either matches, fails, or throws an exception. Searching and backtracking happen implicitly. The language binds variables as it matches, so you walk away with named pieces of data rather than needing to index into positional fields. It supports structured named blocks with nonlocal exits, structured exception handling, and named pattern matching functions. The result is expressive enough to parse formal grammars but simple enough for ad-hoc one-liners at a shell prompt.
TXR Lisp is the second half. It is not a repackaging of Common Lisp or Scheme. It is a new dialect that borrows ideas from many traditions: Common Lisp, Scheme, Awk, M4, Prolog, Ruby, Python, Clojure, and others. The dialect prioritizes succinctness. Programs should be short and clear. If a solution is significantly clearer in another language, the project wants to know about it, because that technique might find its way into TXR.
The two languages tangle together. You can use either one independently, or mix them in the same file. TXR even includes an implementation of Awk as a Lisp macro, which is the kind of recursive self-reference that signals a language designed by someone who thinks about language design for fun.
Compiler and Deployment
TXR Lisp compiles to bytecode for a register-based virtual machine. Individual functions can be compiled, not just whole files. Source files with a .tl extension compile to .tlo files. Compiled files can be concatenated together to load as one unit, and the concatenated output can be gzipped. The compiler is optimizing: it performs jump threading, dead code elimination, constant folding, and data flow analysis. The optimization pass is actively being improved.
For deployment, the save-exe function creates a copy of the TXR executable under a custom name, with a startup expression baked in. That expression typically loads the rest of the application from the same directory. The deployed executable needs its library modules alongside it, but nothing else. No runtime to install, no framework to bundle. The approach is closer to how you would deploy a shell script than how you would deploy a Python application.
Size and Resource Usage
The numbers are modest. The TXR executable is about 1.7 megabytes of compiled code, a little more than twice the size of GNU Awk. Satellite library modules add another 1.5 megabytes. The only external dependency is libffi. Building from source requires GNU Make, GCC or Clang, and a few shell utilities for the configure script. Generated sources ship with the tarball, so you do not need the tools that produced them.
Memory usage is comparable to Bash. At the interactive prompt, TXR sits at a similar footprint. Compiling the entire TXR Lisp standard library, including the compiler itself, peaks at roughly 18 megabytes. That is small enough to run comfortably on embedded systems or in containers with tight memory limits.
The Awk Comparison, Revisited
The project draws an explicit comparison to Awk, and the comparison is instructive. Awk implicitly reads a file, splits it into records and fields, and gives you positional variables. That model works well for uniform, delimited data. TXR's pattern language handles delimited fields too, but it generalizes. Data that changes structure between sections, data with irregular spacing, data that mixes free text with semi-structured fields, all of these are within reach.
The pattern-matching directives are not imperative code. You do not write a loop that reads a line and tests a condition. You write a pattern that describes the shape of the data you want, and TXR figures out how to get there. That declarative style means less boilerplate and fewer off-by-one errors, at the cost of a different mental model than most imperative languages.
Community and Project Status
TXR is free software under the two-clause BSD license. The project has a HACKING guide for contributors and is actively looking for developers. User reports on Hacker News and GitHub describe the language as impressive for its age, with a manual that holds up well. One user described extracting data from bank statement PDFs as significantly easier with TXR than with regex alone.
The project carries a specific warning: do not use the Homebrew package. The TXR team has received reports that Homebrew builds produce unstable executables. The Homebrew formula does not run the test suite, and the build may use compiler features that introduce instability. Building from source on the project's own instructions is the reliable path.
TXR has been around since 2009, which makes it old enough to have a 900-page manual and young enough that most developers have never heard of it. That gap between capability and awareness is often where the most useful tools live.