Limitations of the Current Implementation

  The current version handles all syntactic forms except =>, delay and unquoting. Unquoting is supported in the sense that procedures containing quasiquote and unquotations can de debugged, but it is not possible to step thru an unquotation, or set a breakpoint within a quasiquotation.

Macros are not supported at all. It would require that the instrumentation code would have to keep track of all macro definitions and be able to expand macros in their full glory.

The reader understands symbols, boolean values, strings, vector, characters, integers, simple floats and lists. Fancier numbers like complex numbers etc. are not supported. They are not very hard to implement, they are just not on top of the priority list for me. Hex, octal and binary numbers do work, though, thanks to Edward Briggs.

One thing that psd is not guaranteed to preserve is the order of evaluation. Because of the additional code that psd adds to the program, it is possible that the instrumented version of a procedure call is evaluated in a different order than the original. If the Scheme implementation used evaluates all arguments from left to right or right to left, there is no problem. If, however, the order of evaluation is something more exotic, the order of evaluation may change. In practice this is probably not a problem.

Because the instrumented programs and the runtime support for the debugger live in the same name space, there are some names that can not be used in the debugged programs. In psd, all the globally visible procedures start with the prefix psd-, and variables with the prefix *psd-. Do not use these prefixes in your programs.