Debugging.

Some things that are important:
 * Trace procedures rather than names.                            [DONE]
 * Rename 'breakpt' as 'break-entry'.                             [DONE]
 * Make 'break-here' invoke the debugger at the current location. [DONE]
 * Rename 'break-here' as 'break' (name now held by a primitive)  [DONE]
 * Create a primitive 'debugvsm' to do what 'break' does now.     [DONE]
 * The error handler should invoke the debugger.                  [DONE]
 * Want a 'return-with-values-from-this-frame' command.           [EASY?]
 * Variable names and values                                      [INVOLVED]
 * Stepping                                                       [INVOLVED]


Status.

- The file TRACE.SCH contains the new trace code.  It has been tested and
  appears to do the right thing.  Modulo some grossness to deal with errors
  (see comments in the file header) the new trace code is done.
- The file VARIABLES.SCH contains working code for PROCEDURE-ENVIRONMENT
  for interpreted procedures; this is a work in progress.
- Some vestiges of a new debugger are in NEW-DEBUG.SCH but this is really
  only a start.  Numerous issues about how to use CONTINUATION-EXPLODE
  are unresolved.
- Experimental and untested code for CONTINUATION-EXPLODE is in CALL-CC.SCH.
- Also see file Ertevann:Research:debugger.txt.


Variable names -- this is a work in progress.

- Trace-entry and break-entry now print formal names, if available.
- Need compiler support to map stack slots to variables in a call frame;
  this should not be hard, though getting good space efficiency may
  not be easy.
- Need compiler support to map stack slots to variables in a system
  continuation, to support debugging of primitive exceptions.  This is 
  harder, and space efficiency can be a real problem.
- Have added some hackish compiler support to get map of closed-over
  variables:  Added the following to cg-lambda (in pass4p1.sch) 
  following the bindings of the LET*:
          (doc.formals-set! (lambda.doc exp) free) 
  (This reuses the FORMALS slot, this needs to be fixed).
- The interpreter now supports variable names adequately, although the
  information is not being used yet.
- Need to fix the interpreter's documentation to record closed-over
  variables (?)


Stepping -- not yet started.

- We can support stepping in the interpreter with an *EVALHOOK* mechanism,
  though performance is an issue -- it's important for the interpreter to
  be reasonably fast.
- Observe that if the source code for a procedure is available, then
  an interpreted procedure can be re-preprocessed for stepping if we need
  to step it.  This is even very simple: we can process the code to
  call *EVALHOOK*, and patch the procedure to make sure that identity
  is preserved (the current patch mechanism should be adequate).  Then
  we can just continue execution.  The environment of a LAMBDA
  can be grabbed from the procedure and installed in the re-compiled LAMBDA.
  We must compare current performance to the performance with an empty
  *EVALHOOK* before we start worrying about this hack.
- Compiled code may be able to use a similar mechanism for stepping, though 
  the environment presents more of a problem, because it has a representation
  that is not unlike the representation used by the interpreter.


