Why T2T?

Paul Tarvydas

Oct 14, 2026

Share

T2T means text-to-text transmogrification (transpilation).

Compilers fundamentally work like this - read text in, convert to text out. The other part of compiling is the inclusion of type checking tools which should really be written in inferencing languages, for example Prolog and its descendants.

One of the earliest compilers - cc on early Unix - worked exactly like this. Cc inhaled C code and exhaled PDP-111 assembler code as text. Another tool, as converted the assembler text into binary that could be loaded and run on the computer. Early K&R C was essentially a tool for creating assembler. It popularized some conventions, e.g. the C calling convention, where every subroutine was treated as a function, which required generating extra code. K&R C had limited type checking - just enough to help programmers check their work. Later variations on C - ANSI C - changed the declaration syntax of K&R C, removed the default - that every subroutine was considered to be a function that, by default, returned an int - attempted to make C portable to non-PDP CPU architectures and, generally, twisted C from being a tool for producing PDP assembler to being a tool for type checking that incidentally produced binary code for a plethora of CPU architectures.

T2T shows that we don’t need fancy data structures to accomplish a lot of work.

Strings are fairly simple data structures. String manipulation is supported by most modern languages. The concept of string manipulation was popularized by UNIX pipelines. The main failing of the UNIX tools is that they were based mostly on REGEX, which is a terse, flat notation. T2T uses OhmJS for its front end. Ohm is a proper parser allowing rules to call other rules and allows recursive rules. Hence, T2T can match more interesting structures in text than REGEX can. T2T is more verbose than REGEX. I consider the T2T syntax easier to read than REGEX syntax. Ohm is a top-down parsing language (TDPL) which I find to be significantly more friendly than CFG-based parsing languages, which are bottom-up. Using a TDPL, programmers can write rules that skip over constructs, whereas BUPLs (CFGs like YACC) require a programmer to painstakingly specify every possible incoming token

When stock OhmJS is used, it is expected that the rest of the “semantics” code will be written in Javascript. RWR, though, provides a very simple set of operations and generates OhmJS-compatible Javascript - you don’t need a lot of the complicated features of Javascript to get a lot of useful work done.

The T2T rewriting technique can be used to build tools for program development, say to search through code or to build code that writes code. The “efficiency” rules for program development tools are different from what is needed for product development. A tool only needs to run “fast enough” on development hardware. The goal is to save development time by expending hardware power, instead of saving hardware cycles by expending development time. For example, you can create a little tool / notation that allows you to combine Prolog for type inferencing with another language for doing the actual code emission along with yet another BNF-like language for input parsing.

When you can develop little languages and little tools rapidly, you are freed to use more than one language for any project - this used to be considered problematic back when writing languages was difficult, but, that is no longer the case.

LLMs supposedly generate code. But, they use only one coding style based on the functional / function-based paradigm. There are other ways to write programs, for example Prolog, Forth, Statecharts, etc. which might be more suitable for parts of projects than the function-based style.

A video showing setup and build of an example T2T project is in

. The repository for the code example in the video is in https://github.com/guitarvydas/dictlisp.

T2T is one of the tools in the PBP toolkit — once you install PBP, you have access to T2T.

RWR is part of T2T. This is the specification for RWR

RWR is a little language (a tiny DSL) for string manipulation and rewriting text into other text. RWR is not Turing complete, but, the combination of OhmJS and RWR into a toolset I call T2T (“text to text”) is a powerful text matching and text rewriting tool.

RWR needs only a few operations

• create new text by inserting character constants
• create new text by inserting text interpolated by tree-walking the parameters passed in from the OhmJS parser
• call Javascript support routines that return strings
• push, pop and query user-defined stacks, much like Lisp’s dynamically scoped variables
• this allows information to be passed down the parse tree when tree-walking
• for example, if a rule needs to include a string from higher up in the tree, the string can be constructed (using rewrite operators) and pushed onto a parameter stack
• this is like pass-through parameters supplied to every function, except without the associated syntactic noise
• string creation is recursive - string operators can take parameters that are themselves created strings

Email: ptcomputingsimplicity@gmail.com Substack: paultarvydas.substack.com Videos: https://www. youtube.com/@programmingsimplicity2980 Discord: https://discord.gg/65YZUh6Jpq Twitter: @paul_tarvydas Bluesky: @paultarvydas.bsky.social Mastodon: @paultarvydas (earlier) Blog: guitarvydas.github.io another earlier Blog (raw form): https://github.com/guitarvydas/missing-blogs References: https://guitarvydas.github.io/2024/01/06/References.html Notes and Back of the Napkin Scribbles: https://github.com/guitarvydas/napkin-notes books: WIP Leanpub: https://leanpub.com/u/paul-tarvydas

Paid subscriptions are a voluntary way to support this work.

UNIX was originally written in PDP-7 assembler. Cc appeared in 1972 and emitted code for PDP-11s.↩︎