Turning the automated Printfer into a true debugger

For those so inclined.

The debugging GUI should operate in the trace back frame, when eval has halted. Eval has saved the frame of thecode under test, and I presume, restored the calling frame for the interrupt.  The interpreter developers are the smart ones here, and they made the trace back work well.

So, the trace call backs should set the status and call  the message loop.  From the GUI the user hits the run or step, and that causes an exit from the trace routine, return back to the interrupted eval.

But  true debugger is a different beast, a different path from the automated printfer.  I am more interested in improving the printfer function, like intelligent watch on function variables, or organize the watch variable for everything inside a function call, on the run.  Make it an intelligent printfer.

The code keeps the local and global dictionaries for the system under test, and these dictionaries hold symbol and value.  Lot's of stuff to find out from those dictionaries, which if intelligently presented, makes the errors obvious.

It was the same with the music project.  Once I had a simple wave tone generator, then the real interesting stuff becomes a score language processor, able to make chord sequences,move score and melodies up and down the scale, space filling with beats and rests. It is always the language, the allowable sequences of tokens that become an interesting project.

A real clear market for intelligent printfing is code verification.  Descend the sequence, as a compact graph, take with youn the range limits that allow any node to be traversed, make sure you get a finite graph.  So, create the entire class of token processing, working from keywords and variable names.  You are not a compiler, you are working in straight symbol space, making sure symbols in conditionals are strictly range bound, stuff like that.  Great for finance, make their transaction code spoof proof, huge market.