issue OPTIMIZE-DEBUG-INFO

[David N Gray <Gray@DSG.csc.ti.com>]

Here is a little problem that has been bothering me; I'd like to see what
other people think about it.  I'm offering two possible solutions; the second
is the one I prefer even though I have implemented the first as a temporary
stop-gap.

  -- David Gray

--
 
Issue:		OPTIMIZE-DEBUG-INFO
References:	CLtL p. 160
Category:	CLARIFICATION or ADDITION
Edit History:   9 Sep 1988, David Gray (initial version)
Status:		for preliminary discussion
 
Problem Description:

  The OPTIMIZE declaration provides a way to tell the compiler how important
  various qualities are in order to guide which optimizations are done.
  There is another quality, however, that is not mentioned, but is an
  important consideration for the compiler:  how much information
  should be included in the object code to facilitate debugging.  This
  includes both annotation added to enable a debugger to display more
  information to the user, and also suppression of optimizations that would
  confuse debugging by making it harder to connect the object code with the
  source code.

-- 

Proposal OPTIMIZE-DEBUG-INFO:SAFETY:  (CLARIFICATION)

  In the description of the OPTIMIZE quality SAFETY, replace "run-time error
  checking" with "run-time error checking and ease of debugging".
 
 Rationale:

  If the user is concerned about detection of errors, then he is presumably
  also interested in being able to easily debug those errors when they are
  signalled.  (However, this is not always true.)  While this is not very
  compelling reasoning, it seems to be the best interpretation that can be
  made without either extending the language or adding some
  implementation-dependent switch.
 
 Current Practice:

  This is the approach taken by the TI Explorer.
 
 Cost to implementors:

  Minimal, since it only affects implementations that choose to make use of
  it.
 
 Cost to users:

  None.
  
 Benefits:

  Facilitates consistent use of declarations by different implementations.

--

Proposal OPTIMIZE-DEBUG-INFO:NEW-QUALITY:   (ADDITION)

  In the description of the OPTIMIZE declaration, add an additional quality
  named DEBUG, described as "ease of debugging".
 
 Rationale:

  Since ease of debugging is an issue that the user will be concerned with,
  and is an issue that the compiler needs to consider, this provides a clear
  way for the user to control the amount of debugging information placed in
  the object module, with DEBUG=0 meaning none and DEBUG=3 meaning "as much
  as possible".
 
 Current Practice:

  No current implementation of this is known.
 
 Cost to implementors:

  All would have to update their handling of OPTIMIZE declarations to accept
  the new quality.
 
 Cost to users:

  One more little feature to learn.  Some problems may result from the
  addition of the symbol DEBUG to the LISP package.
  
 Benefits:

  Provides users a standard way to control the interaction between
  the compiler and debugger, and saves implementors from having to invent
  implementation-dependent solutions.

--

Costs of Non-Adoption: 

  Continued confusion about how debug information should be controlled.
 
Discussion:

  The second proposal seems to be a more ideal solution, but has a higher
  cost.  It would be more attractive if someone can find a suitable symbol
  that is already in the LISP package.  [The best I can see offhand is
  INSPECT, but (DECLARE (OPTIMIZE INSPECT)) doesn't seem as intuitively clear
  as (DECLARE (OPTIMIZE DEBUG)).]

  Concern has been raised that there is already a problem with the
  non-orthogonality of SPEED, SAFETY, and SPACE that would be made even worse
  with DEBUG added, since users are largely perplexed by the interactions of
  these qualities.  [I don't really understand what the problem is here so
  don't know how to explain it properly.]