Re: issue OPTIMIZE-DEBUG-INFO

[Rob.MacLachlan@WB1.CS.CMU.EDU]

I favor OPTIMIZE-DEBUG-INFO:SAFETY with reservations.

I'm not sure how important it is that debug-info dumping be controlled in a
portable way, since the perception of debug-info "goodness" is
fundamentally dependent on using the debugger, which is implementation
dependent.

I do think that the definition of the SAFETY quality should be broadened.
This could include allowing the SAFETY quality to control debug-info at the
implementation's discretion.

To me, safety means that system integrity will be maintained, and
ill-defined operations will signal errors rather than producing meaningless
results.  The more work the system does to ensure that the program will run
in all Common Lisp implementations, the safer it is.  The current
definition of safety as "run-time error checking" is too narrow, since some
error checking can be done at compile time, but might be suppressed if
COMPILE-SPEED is important.

Debuggability means that once you are in the debugger, you will be able to
tell what the hell is going on.  This is related to safety:
 -- If system integrity is badly damaged, you may not make it into the
    debugger.
 -- If nobody checks for errors, then you will never end up in the debugger
    (modulo breakpoints, etc.)
Safe code is a pre-requisite for debuggable code, so debuggability can be
considered "additional safety".

I am opposed to requiring the system to control debug-info generation in
any particular way.  Debug-info need not be controlled by the compiler at
all: it could be conditionally GC'd away at system build time.

  Rob