Code Sketch - Paper Trail

January 2, 2014

Kris Jordan

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"
    data-papertrail-href="/posts/1" 
    data-papertrail-property="title"
    >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

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.

Recent Posts