[plt-scheme] ATTN: Neil Van Dyke (and some philosophical musings on debuggers)

For the hell of it, my basic thoughts are that a debugger's critical role
in life to enable the programmer to more easily disambiguate between what
they meant, vs. actually expressed; as we all know it's often more difficult
than may appear at first glance/attempt; often because input domains are
more subtlety complex than originally perceived, resulting in unintended
result ranges or discontinuities which may or may not OBSERVABLY violate the
input domain assumptions of dependant expressions of intended behavior.

I've HIGHLIGHTED "OBSERVABLE" because the critical functionality of a
debugger must be able to enable the programmer to "OBSERVE", experimentally
"CONTROL", and ideally alter, any arbitrary expressed behavior within a
program to aid in the identification and corresponding refinement of desired
expressed behavior to increasingly comprehensive input domains, without
having to alter the program itself to do so.

As data invariably affects conditional control flow, which in turn affects
dataflow, and therefore state; a debugger must then also ideally enable the
control flow state and history to also be both observable, and controllable
to aid in the programmers identification of their insufficient or erroneous
expression of intent beyond the programs natural points of observably and
controllability.

Although contracts assist in the confinement of anticipated data domains
and ranges; they are themselves expressions subject to programmer errors,
nor do they attempt to typically quantify the correctness or the value
discontinuities of transformations that exist between their boundaries, as
if they did, would be fully redundant to the transform descriptions
themselves.

Although I profess to being strongly biased toward the scheme programming
language/style, most/all scheme programming environments severely lack any
comprehensive debugging (arbitrary program/data control/observably)
facilities; as such, they often relegate the task of "debugging" to the
programmer's own wits, which often limit's the commercial use of scheme to
relatively simple problems, academic exercises, or the curious; as without
a reasonably comprehensive means to observe, isolate, and remedy "bugs" in
reasonably complex programs with correspondingly complex datasets, it's
difficult to leverage in environments where programmers are use to, and rely
(for good or bad) on such conveniences. I for one would love to have access
to a more nimble way to arbitrarily observe, control, and refine the
behavior of a scheme program, and spend less time (often invasively), making
due otherwise (as if I knew how to always comprehensively express what I
meant with sufficient precision, I would, but admit to not being
omniscient). 

No prejudice, conflict, or disparity intended, just my two cent thoughts,

-paul-