Add debugger REPL

[phoe]

In the default SBCL repl, we can do debugger-oriented programming like this:

* (foo 42)
; in: FOO 42
;     (FOO 42)
; 
; caught STYLE-WARNING:
;   undefined function: COMMON-LISP-USER::FOO
; 
; compilation unit finished
;   Undefined function:
;     FOO
;   caught 1 STYLE-WARNING condition

debugger invoked on a UNDEFINED-FUNCTION in thread
#<THREAD "main thread" RUNNING {1004A88103}>:
  The function COMMON-LISP-USER::FOO is undefined.

Type HELP for debugger help, or (SB-EXT:EXIT) to exit from SBCL.

restarts (invokable by number or by possibly-abbreviated name):
  0: [CONTINUE      ] Retry calling FOO.
  1: [USE-VALUE     ] Call specified function.
  2: [RETURN-VALUE  ] Return specified values.
  3: [RETURN-NOTHING] Return zero values.
  4: [ABORT         ] Exit debugger, returning to top level.

("undefined function" 42)

0] (defun foo (x) (* x x))
; No debug variables for current frame: using EVAL instead of EVAL-IN-FRAME.
FOO

0] 0
1764

This is harder to achieve in Slime because the debugger does not allow the REPL to be easily used (the *slime-repl sbcl* buffer blocks) which prevents us from writing the function directly in the REPL. The ways around this are using C-c C-c to compile forms in a separate thread or using the debugger's eval-in-frame functionality, which was really not designed for that kind of use.

---

I propose extending the current eval-in-frame behavior and adding a functionality that allows the debugger to drop back into the REPL at a given stack frame. The way I imagine, upon choosing such an option, the debugger buffer can disappear and control can go back into the REPL, with the prompt changed to e.g. [1] CL-USER> to signify that we are debugging. The user can then evaluate whatever they'd like and finally evaluate some sort of keyword command, e.g. :debug, that will get intercepted by the REPL and show the debugger buffer again. (Of course, control can also leave the debugger by means of throwing or invoking restarts, at which point the REPL returns to normal.)

Benefit: interactive and debugger-oriented programming will get easier if the standard REPL is constantly available, even while debugging.

---

Labels: feature-request

[joaotavora]

FWIW, Sly has this. And if I'm not terribly mistaken, so does SLIME... it's been a long time, but I think it's a question of pressing enter in the REPL and you get a new prompt.

[phoe]

You're right! I haven't tested hitting Enter in the REPL; I assumed that a lack of prompt means that the REPL does not accept input. Thanks for the update.

[joaotavora]

instafeature!

[contrapunctus-1]

I assumed that a lack of prompt means that the REPL does not accept input.

Sounds like a UI/discoverability issue - could SLIME display a prompt here, then? Seems like quiiite a few experienced users weren't aware of this possibility 🙂

[phoe]

Yes. Discussing this discovery on #lisp on Freenode caused quite a few brows to rise, and some of these brows belong to old-timers much more experienced than me.

[joaotavora]

Sounds like a UI/discoverability issue - could SLIME display a prompt here, then?

If I remember correctly, I tried to do this back in the day, then discovered it wasn't so easy (or at least "clean"), which is one of the reasons I started rewriting the REPL for what would become Sly (which btw also shows an indicator of debugger "depth").

[luismbo]

@phoe I'm working on integrating João's REPL back into SLIME. Ping me if you'd like to help.

[phoe]

@luismbo I would, but I am completely out of spoons at the moment. Thank you for the porting work.

[joaotavora]

@phoe I'm working on integrating João's REPL back into SLIME. Ping me if you'd like to help.

I think you best start with the cats 🐈 , meow!