// HACKER NEWS — CYBERSECURITY
Experiment – Projectional Viewer
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.
I started from a small, real example: a phone-number grammar written in Rebol, implementation detail and all.
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:
To get from one to the other automatically, I had Claude Sonnet 5 Code write an Emacs Lisp file, pelide-view.el, that shells the buffer (or region) out to a small pipeline built on T2T: an OhmJS parser followed by RWR rewrite semantics. The pipeline reads the annotated source and hands back the elided grammar, which the elisp code then displays back in the editor.
The grammar for the pipeline’s parser (pelide.ohm) and its rewrite rules (pelide.rwr) are in the appendix, as is the generated pelide-view.el. The rest of the code lives in the github repo.
Given the time available, I only ran this against the one example above. Whether it generalizes to messier grammars is an open question.