Hacker News Reader

Comment by TacticalCoder | Hacker News Reader

That sounds intriguing as a Clojure dev but what happens in the following case (not very lispy code but it's just to show what I don't get):

    (do-it (do-it first))

What if (do-it first) works fine, but it's the call to (do-it (do-it first)) that fails?

I get control right where it's broken, so I can fix the do-it defun. Great, I like that. But by fixing it, this means I changed the result of (do-it first).

So the point at which the machine (?) is is a point that's unreachable anymore by the current code.

I hope my example is clear enough.

I really don't understand how that works when fixing what would allow you to continue would change the state at which you're given control to fix things?

View on HN

Please excuse the really contrived example, but you can do this in Gambit:

    ~ cat do-it.scm
  (define (do-it x)
    (if (> x 0)
        x
        'error))
  
  (define (do-it-fixed x)
    (if (and (number? x) (> x 0))
        x
        'error))
  ~ gsi do-it.scm -
  > (do-it (do-it 0))
  *** ERROR IN do-it, "do-it.scm"@2.7 -- (Argument 2) REAL expected
  (> 'error 0)
  1> ,b
  0  do-it                   "do-it.scm"@2:7         (> x 0)
  1  (interaction)           (stdin)@1:1             (do-it (do-it 0))
  2  ##main                  
  1> ,e
  x = 'error
  1> (set! do-it do-it-fixed) 
  1> ,(c x)
  error
  > (do-it (do-it 0))
  error

Per the Gambit docs[1], "The nested REPL’s continuation and evaluation environment are the same as the point where the evaluation was stopped.". The call to ,(c x) is really just calling the reified continuation c with argument x.

[1]: https://gambitscheme.org/latest/manual/#Debugging

you didn't necessarily change the result of (do-it first), you may have, but that just means you introduced another error.

i think the approach here is to accept that you fixed the bug for the second call, but you will still have to go back and retest the first call.

Lisp used to specialize in offering extravagantly expensive features, maybe time travel debugging would be a good addition.

> you didn't necessarily change the result of (do-it first)

You're right.

> i think the approach here is to accept that you fixed the bug for the second call, but you will still have to go back and retest the first call.

Gotcha. It looks like a very useful feature. I may actually just try it to try to understand how it works: especially since TFA says the CL integration with Emacs is good (I happen to be an Emacs user).

Reply on news.ycombinator.com