--- title: "ChatGPT Transcript: OMeta vs Racket vs MPS" description: "ChatGPT Transcript: OMeta vs Racket vs MPS URL: https://chatgpt.com/c/69e00097-c1d0-83ea-9e6e-79999076e370 Title: OMeta vs Racket vs MPS Date: 2026-04-15 Research Context: Option E - Meta-Compilation …" doc_version: 1 last_updated: 2026-10-15 canonical_url: "http://parc.yolo.scapegoat.dev/note/research/institute/research/2026/04/15/compiler-writing-hn/transcripts/chatgpt-ometa-racket-mps" --- # ChatGPT Transcript: OMeta vs Racket vs MPS ChatGPT Transcript: OMeta vs Racket vs MPS URL: https://chatgpt.com/c/69e00097-c1d0-83ea-9e6e-79999076e370 Title: OMeta vs Racket vs MPS Date: 2026-04-15 Research Context: Option E - Meta-Compilation … ## Content # ChatGPT Transcript: OMeta vs Racket vs MPS **URL:** https://chatgpt.com/c/69e00097-c1d0-83ea-9e6e-79999076e370 **Title:** OMeta vs Racket vs MPS **Date:** 2026-04-15 **Research Context:** Option E - Meta-Compilation & Extensible Languages --- ## User Query > Explain the key differences between OMeta, Racket's #lang system, and language workbenches like MPS. What are the trade-offs between these extensible language approaches? --- ## Assistant Response ### Initial Analysis The boundary that matters most is where extension happens: parser/pattern engine, module language, or full AST/editor/tooling stack. I'm pulling one primary source for the semantics of each and one source for the tooling implications. ### Core Differences The cleanest way to see the difference is this: | System | Center | Approach | |--------|--------|----------| | **OMeta** | Parser-centered | Object-oriented pattern-matching language built on PEG-style recognition, extended to work on arbitrary data | | **Racket #lang** | Expander/module-centered | Packages a reader plus an expander into a module language selected by #lang, with macros operating on syntax objects | | **MPS** | Model/editor-centered | Users edit the AST directly through a projectional editor; language definition includes structure, editor, type-system, and generator aspects | Note: "Language workbench" is broader than MPS specifically; Fowler's broader category includes tools with different editing models, while MPS is the projectional end of that spectrum. ### Trade-off 1: Syntax Freedom vs. Text Simplicity **MPS wins on freedom:** No parser means you can have tables, forms, diagrams, context-sensitive notations, and multiple views over the same AST. **OMeta and Racket** are still fundamentally textual, even when they are highly extensible. OMeta can compose grammars and add local syntax, and Racket can replace or extend the reader, but both are still working through textual input and parsing/reading. **Practical implication:** If your goal is "invent any notation the domain needs," MPS is strongest; if your goal is "keep a normal text workflow," OMeta and especially Racket are more natural. ### Trade-off 2: Tooling Burden vs. Host-Language Leverage **OMeta** is comparatively lightweight: it gives you a very expressive way to define syntax, matching, and transformation, positioned as "rapid prototyping," but it is not presented as a complete language packaging and IDE system. **Racket** goes further: a language can hook reader and expander layers while staying inside a shared module/tool ecosystem. **MPS** goes furthest: editor, type-system, generator, and other aspects are part of the language definition itself. The price is more up-front work; JetBrains' own materials emphasize that MPS language definitions can be time-consuming and that each concept needs editor support. ### Trade-off 3: Compositional Safety **Racket is strongest here** because syntax objects preserve lexical information and macro expansion explicitly tracks scopes and phases, which is what makes hygienic macro composition practical. **OMeta** is powerful but more operational: semantic actions are host-language code embedded in the grammar, and backtracking does not rewind their effects, so authors must manage those interactions carefully. **MPS** sidesteps a different class of problems by eliminating parse ambiguity altogether, but that does not mean semantics are "free"; you still have to define constraints, typing rules, and generators coherently. In other words: Racket gives the strongest built-in story for binding-safe syntactic abstraction, OMeta gives rawer control, and MPS gives structural composition more than lexical/macro composition. ### Trade-off 4: User Experience **OMeta** is pleasant for language implementers who are comfortable living close to grammars and transformations. **Racket** is usually the best fit when the target users are programmers who want a real text language, normal files, and interop with a larger runtime and tool suite. **MPS** becomes attractive when the target users include domain experts or when the notation really should not look like plain text code. But projectional editing is a genuine culture shift: JetBrains notes that users often need a few days to get used to it, and because persistence is not pure text, diff/merge requires special tooling. ### Practical Summary | Choose... | When... | |-------------|---------| | **OMeta** | You want a very malleable grammar-and-transformation substrate | | **Racket #lang** | You want serious language extension inside a textual programming ecosystem | | **MPS** | The language definition must include the editor and when syntax should be structurally composed rather than parsed | The main trade-off is not "which is more extensible," but **which layer you want to make extensible**: parser, compiler front end, or the whole language-plus-IDE stack. --- ## Key Sources Referenced - Tin Lizzie (VPRI papers on OMeta) - martinfowler.com (Language Workbenches article) - Racket Documentation (#lang system) - JetBrains MPS documentation ## Sitemap - [Home](http://parc.yolo.scapegoat.dev/) - [Home markdown mirror](http://parc.yolo.scapegoat.dev/index.md) - [Markdown sitemap](http://parc.yolo.scapegoat.dev/sitemap.md)