Friday, March 07, 2008

Crazy debugging feature idea

Here's a crazy idea. Closures are like objects with private fields, right? Specifically, outside of the function body, you're not allowed to refer to the variables in the closed environment. But one of the most annoying things that happen when I'm debugging is that I want to call some local function, but it's not available from the REPL:
(define (foo x y)
(define (helper z)
... x ... y ...)
What if, at the REPL (i.e., in debug mode only), closures were openable? You could use dot-notation to refer to them, and all you'd have to do is somehow provide the extra bindings needed to fill in their environment. Keyword arguments, maybe?
> ((close foo.helper [#:x 42] [#:y 'blah]) "value of z")


dh said...

That's exactly the point, why I do not regard scheme as a reflective language: you cannot inspect closures. You shouldn't need a special debugger to peek into a closure. Are closures the way we have them in scheme already too much of an abstraction barrier?

Anonymous said...

Err, that's what I did in Mobit Scheme, and it is also (I think) how closures in Gambit are serialisable. Though your version is (maybe) a bit more user friendly with respect to syntax.


Unknown said...

It depends upon your language, but the idea is not so crazy really. For example, in Scala first-class »functions« are really just instances of the class Functionn. I do not know the details of how lexically captured entities are compiled, but it seems reasonable that they could be represented by fields and methods of the object. Therefore, your example could be considered to generate an object with the type:

Function2[?,?] { def helper(z : ?): ? }

(I've inserted question marks for the types.)

Of course the tricky bit is that most things will be expecting what you've constructed to have the type Function2[?,?] so the refinement on the type will quickly be lost. So to call the helper method you would need to either use an unsafe cast or reflection.

(Blogger doesn't accept <code> or <tt>???)

Jay McCarthy said...

Look at the map-closure paper from POPL 07.

Anonymous said...

Maybe also relevant: Eijiro Sumii and Hideo Bannai. 2003. The extension of ML
with hypothetical views for discovery science: Formalization and
Journal of Functional and Logic Programming 2003.

dh said...

Jay, thanks for the hint to the map-closure paper. That was a very interesting read.

pnkfelix said...

Dave: I hacked a special form up this morning that allows you to define inspectable closures. (Yes, it is not what you asked for, since you described something where the closure defining code does not need to explicitly provide access to its free variables via a new form; still, it might be a useful point to explore in the design space.)

See post below (includes code):