Re: Issue: DESCRIBE-INTERACTIVE (Version 3)

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

    I oppose DESCRIBE-INTERACTIVE:NO on the grounds that it creates
    extra work for implementors and users of at least one implementation,
    for no compelling reason.
    
I have to disagree that there is "no compelling reason".  The problem
centers on whether on not you believe that portable programs should be
able to describe objects to users (and how compelling you feel that
need is).

    Instead of eliminating functionality from DESCRIBE, it would be better
    to suggest that DESCRIBE methods (and any other programs that ask
    questions of the user) should call the recently added
    STREAM-INTERACTIVE-P function (I'm not sure I've got the right name) so
    as to avoid asking questions when there is no one to answer them.  This
    would address the stated goal "to call DESCRIBE in a batch applications
    without hanging the application" without requiring incompatible changes
    to current practice.

Unfortunately an implementation suggestion does not license portable
programs to rely on it.  While your proposal might increase the
probability that a portable program that called DESCRIBE wouldn't
break, it doesn't eliminate it.

In general, I don't see what the world gains from having DESCRIBE be a
restricted INSPECT instead of an output-only function.  On the other
hand, I don't want to waste a lot of everyone's time arguing this.