Debugging is a recursive process to find out

the value of a variable or expression
what gets executed, or mostly, which branch of a conditional gets executed

When I don’t get what I expected, I have to go deeper and deeper into the misbehaving expression, explore expressions and their subexpressions. The simplest debugging technique prints out values (case #1) and messages, like I was here (case #2). Stepping through the code in a debugger does almost the same, without having to modify the code when I change focus, and want to explore another value. But they are both linear approaches.

Synopsis, or seeing all at once

I want to see everything in a context at once. Most debuggers display the value of variables in the current context. To display values of nested expressions, they would need a time-machine, either to remember expressions already evaluated, or to foresee an expression to be evaluated. Let me give an example in Clojure, the idea is supposed to work for also other languages, though.


(if

  (and

    (number?
  x)

    (even? x))

  "We are even"

  "It's odd")



 "It's odd"

 false

 false

 nil

 "It's odd"

and compare it to this


(if

  (and

    (number?
  x)


    (even?
  x))

  "We are even"

  "It's odd")



 "We are even"

 true

 true

 42

 true

 42

 "We are even"

I can see what gets executed (colored) and what doesn’t (white). I look at the first case, and without checking the return values, I already know that (and ...) returns false because of shortcircuiting. If I want to know the value of a subexpression, I just look at the return values with the same color.

This is where the development of lambdebug is just heading now.

A final note about the name. When I first had this idea, I didn’t know about Rainbox parenthesis, the vim plugin to display lisp code in a colorful way. When I bumped into it, I liked its name, so I borrowed it.