Light Table is a exciting experiment to build an IDE featuring pervasively direct-manipulation. In the process of trying out its Instarepl, I experienced three noteworthy limitations: invisible intermediate results, hidden recursion, and awkwardly located output with no ability for input.

I’m sure Chris Granger and the other people at Kodowa are hard at work laying a sound foundation for Light Table and experimenting with mechanisms for making a great Instarepl. I want to look at these three issues because the pose interesting design questions well worth contemplating.

Invisible Intermediate Results

Suppose we ask who the winner-is in a little game:

The Instarepl instantiates variables, but it doesn’t show us the results. In order to see the return value of a function, we need to use a let form:

Naming intermediate results is sometimes a good idea, but we shouldn’t modify code to accomidate the tool: the tool should accomidate us. A better Instarepl would show us the intermediate steps in a final reduction.

Hidden Recursion

The right column of the Instarepl copies your source instantiating variables in functions. A nice consequence is that repled code has the same structure as the original source. A negative consequence is that each function can only be instantiated once. Recursion looks particularly ridiculous:

Fundamentally functions are used to factor out repeated reduction patterns. It is only natural for named functions to be reused.

Awkward Output / No Input

The Instarepl has incomplete handling for even simple IO. Reading from *in* is unavailable: results in a EOF while reading. Output to *out* is collected at the bottom:

With output at the bottom, we loose the context which leads to its generation. What better way might we represent IO in an Instarepl?

For next time.