Code Sketch: Paper Trail

Often I'll have an idea that's interesting to me. I'll obsess for a weekend, sketch out some proof-of-concept code, prove to myself it'd be possible (with a lot of work), or not, and move along.

Sometimes these sketchy ideas are recurring. "Paper Trail" is one of them; it first surfaced circa 2009.

Rather than sketching ideas in private, I thought it'd be interesting to do publicly. Ridicule away.

This idea's motivation is a thought experiment:

What if you could trace every value in a program all the way back to its source at runtime?

This isn't a novel idea. Spreadsheets have been doing this forever, right? For example, assign `1` to cell A1 and `=A1+1` to cell B2. The output value of cell B2 will be `2`, but you can later trace its source back to A1.

It is a foreign idea, though, in general purpose programming languages. For example, assign `a = 1`, then assign `b = a + 1`. The value of `b` is now `2`, but there's no way to know, at runtime, its source is `a`.

Why is this interesting?

Imagine a database-driven website's execution flow. The source of data is now the database, rather than hard coded values. Let's wave our hands with pseudo-code:

# Fetch a blog post
post = Post.first()
# Render template with blog post
render(template, post)
# Print title of blog post in template
<h1>{{ post.title | toUpperCase }}</h1>

The rendered output would be:

<h1>HELLO, WORLD.</h1>

Now imagine a "paper trail" of back references was baked in by default through that program listing. The template engine could just as easily also render (if it wanted to, for content editors):

<h1 class="papertrail-value"
    >HELLO, WORLD.</h1>

Sprinkle in some JavaScript magic and voilà, front-end content editing becomes possible without the trade-offs it traditionally imposes on front-end developers:

  • no constraints on template structure
  • no additional work and effort
  • no new DOM tags
  • no ugly widgets forced in

It'd be powerful.

Interesting follow-on questions and problems fall out quickly:

  • What would it take to implement this in user land?
  • What about sources that are collections rather than objects?
  • What about values that combine multiple source values, like string concatenations?
  • How much overhead would this impose? Would it actually matter?
  • Is there value in storing the whole trail or just the source(s)?
  • Is there any value if the source is read-only?
  • What other applications would a reference trail have?
  • How much work would a proof-of-concept take?

I'm going to keep sketching on this, at least through the weekend, and worst case when it resurfaces for me again in a few years.

Sound interesting to you? Ping me @KrisJordan.