Skip to content
Tech News
← Back to articles

Experiment – Projectional Viewer

read original get Crafting Interpreters by Robert Nystrom → more articles
Why This Matters

A developer's small experiment tests whether code editors can hide implementation detail from view rather than strip it from source, using a Rebol PEG-style phone-number grammar as the test case. It's a pragmatic, one-way take on projectional editing: elide for reading only, skipping the hard problem of editing the collapsed view and writing back. The broader implication is a path toward composing many small domain-specific languages in one codebase instead of squeezing every concern through a single general-purpose paradigm.

Key Takeaways
Worth a Look

Crafting Interpreters by Robert Nystrom — If you're deep in PEG grammars and wondering how much plumbing a parser really needs, Crafting Interpreters walks you through building two complete language implementations from scanner to interpreter. It's a hands-on companion for anyone experimenting with editors, grammars, and separating a language's structure from its mechanics.

See Crafting Interpreters by Robert Nystrom on Amazon → Affiliate link — we may earn a commission on purchases, at no extra cost to you. Product picked by AI based on this article; it is not a tested recommendation.

Purpose

Modern programming languages bury structure under implementation detail. The signal-to-noise ratio is too low — there’s too much how cluttering up the what — and that makes it hard to reason about anything beyond fairly simple problems.

This experiment asks whether implementation detail can be elided from code, rather than removed. The detail stays in the source; it’s just toggled out of view in the editor. The goal is a clearer picture of a solution’s structure, without having to wade through the mechanics of how that structure gets executed.

The immediate irritant was PEG (parsing expression grammar) libraries. I know grammars reasonably well, and most PEG implementations I’ve used smear the grammar itself under a layer of code for capturing and acting on matches during and after the parse. The grammar — the actual structure of what’s being recognized — disappears into the plumbing.

A full round-trip projectional editor, where you edit the elided view and it writes back to the source, is hard to build well. So this experiment settles for a one-way trip: elide the detail for reading, without trying to support editing the elided form. The question is whether that lesser goal is easy to reach and still worth having.

Underlying this is a way of treating a “grammar” as a DSL for pattern matching — one little language embedded in another. If eliding works here, it suggests a broader path: composing many small special-purpose languages into a single codebase, instead of forcing every concern through one general-purpose paradigm.

Method

I started from a small, real example: a phone-number grammar written in Rebol, implementation detail and all.

parse "(416)555-1234" [ "(" copy area 3 digits ")" copy exch 3 digits "-" copy line 4 digits (print rejoin [area "-" exch "-" line]) ]

The copy area , copy exch , copy line , and the trailing (print rejoin ...) block are all implementation detail — they’re about capturing values and doing something with them, not about the shape of a valid phone number. Stripped of that, the grammar itself is just:

... continue reading