Issue: DESCRIBE-INTERACTIVE (Version 3)

[Dan L. Pierson <pierson%mist@multimax.ARPA>]

As promised, this is a complete reversal of Version 2.

!
Issue:        DESCRIBE-INTERACTIVE
References:   DESCRIBE (p441)
Category:     CLARIFICATION/CHANGE
Edit history: 12-Sep-88, Version 1 by Pitman
              23-Sep-88, Version 2 by Masinter
	      19-Oct-88, Version 3 by Pierson, invert

Problem Description:

  CLtL is not clear about whether DESCRIBE may be interactive.
  While CLtL describes INSPECT as an interactive as an
  interactive version of DESCRIBE, it doesn't make explicit
  that DESCRIBE is non-interactive. In some implementations it is, 
  and in other implementations it is not.

  Users of systems in which DESCRIBE is not interactive may presume
  that it is safe to call DESCRIBE in a batch applications without
  hanging the application, which can lead to problems.

Proposal (DESCRIBE-INTERACTIVE:NO):

  Specify that DESCRIBE is forbidden to prompt for or require
  user input.  Permit implementations to extend describe via keyword
  arguments to prompt for or require user input as long as the default
  action if no keyword arguments are supplied does not prompt for or
  require user input.

Test Case:

  The following kind of interaction would be permissible in
  implementations which chose to do it:

   (DEFVAR *MY-TABLE* (MAKE-HASH-TABLE))
   (SETF (GETHASH 'FOO *MY-TABLE*) 1)
   (SETF (GETHASH 'BAR *MY-TABLE*) 2)
   (SETF (GETHASH 'FOOBAR *MY-TABLE*) 3)
   (DESCRIBE *MY-TABLE* :INTERACTIVE T)
   #<EQ-HASH-TABLE 259> has 3 entries.
   Do you want to see its contents? (Yes or No) Yes

Rationale:

  DESCRIBE is the only hook a portable program has for providing
  information about objects to the user.  The potential interactive
  functions of DESCRIBE are also likely to be available via INSPECT.

Current Practice:

  Symbolics Genera asks some questions interactively when describing
  some kinds of structured data structures, such as hash tables.
  Since users can define their own DESCRIBE methods and took their cue
  from the system, describing some user structures also require such
  interactions.

Cost to Implementors:

  Symbolics Genera and other non-conforming implementations will have
  to change.

Cost to Users:

  User code which depends on DESCRIBE running with user interaction
  will have to be modified. Such code is not currently portable,
  however.

Cost of Non-Adoption:

  Users would not have any portable way to have progams inform the
  user about object they are dealing with.  This might be important in
  traces and logs of portable progams or in portable debugging tools.

Benefits:

  It will be easier to provide some types of portable functionality.

Aesthetics:

  This simplifies the language slightly.

Discussion:

  Pitman thinks it's important to clarify this issue, but he isn't fussy
  about the particulars.

  It might be possible to extend DESCRIBE to have additional 
  keywords (:VERBOSE, :INTERACTIVE-ALLOWED) to cover 
  additional behavior. 

  Pierson thinks it's important for there to be some way for portable
  programs to present this sort of information to the user.  While the
  exact data and format presented is implementation dependent and thus
  outside of the bounds of standardization, the existance of such data
  is neither.