possible debugger architecture

[Raoul Duke]

brainstorming with the help of Claude

https://docs.google.com/document/d/16sZOnoe5Wz5oc9qGfr3LdI8Z6vy8NYwQcGVkmPkSauo/edit?usp=drivesdk

[dr.mt...@gmail.com]

As is usual with AI stuff one is initially overwhelmed by the volume of material.

I think that Claude may have got too focused on KL.   A KL frame is actually

not really what you need in debugging Shen.   The KL variables are machine

generated and offer no insight beyond the tracker in the kernel code.   The

variables you need are in the Shen source - a Shen frame would be more useful.  

ChatGPT says

In fact, if you look at good debuggers:

• • GDB,
  • SBCL debugger,
  • SLIME,

they aggressively hide VM machinery unless explicitly requested.

A “KL disassembly” mode could still exist for experts, but it should be subordinate.

Your real abstraction is probably closer to:

(@p shen-frame

Function

Clause

Bindings

Source-Loc

Continuation)

where continuation is something intelligible like:

(return-to factorial)

(waiting-for arg-2-of-+)

rather than raw evaluator continuations.

Otherwise the debugger becomes a debugger for the debugger.

I suspect the real architectural mistake in Claude’s document is this:

it treats KLambda as the user language.

But KL is intermediate representation.

Mark