DESCRIBE-INTERACTIVEDESCRIBE 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.
DESCRIBE is permitted (though not required) to require user input, and that such input should be negotiated through *QUERY-IO*.
Descriptive information would continue to go to *STANDARD-OUTPUT*.
(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*)
#<EQ-HASH-TABLE 259> has 3 entries.
Do you want to see its contents? (Yes or No) Yes
DESCRIBE methods and took their cue from the system, describing some user structures also require such interactions.DESCRIBE running without user interaction would have to be modified. Such code is not currently fully portable, however.DESCRIBE.DESCRIBE only because they're not 100% sure it's kosher would be free to do it.DESCRIBE to require user intervention. Not saying whether it's permissible is probably less aesthetic, though.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.
This is an incompatible change for some implementations.
(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
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.DESCRIBE methods and took their cue from the system, describing some user structures also require such interactions.DESCRIBE running with user interaction will have to be modified. Such code is not currently portable, however.
EXPLICITY-VAGUE proposal is the minimal proposal for compatibility with current behavior.
Some members of the cleanup committee think that EXPLICITLY-VAGUE is really a change from the intent of CLtL. However, the current sentiment is to be less rather than more specific about the behavior of debugging tools (25.3 of CLtL).
It might be possible to extend DESCRIBE to have additional keywords (:VERBOSE, :INTERACTIVE-ALLOWED) to cover additional behavior.
Pierson supports NO because he 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.
Moon opposes NO because "it creates extra work for implementors and users of at least one implementation, for no compelling reason."
Moon suggested as a compromise only allowing DESCRIBE to require user input from "interactive streams". Several other members of the committee like this in principle but question whether it's feasible since we have neither defined "interactive streams" nor provided any portable way to tell if a stream is interactive.