[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Issue: DESCRIBE-INTERACTIVE (Version 3)



    Date: Mon, 31 Oct 88 14:17 EST
    From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>

    ... I believe they should, but I don't feel that the
    DESCRIBE-INTERACTIVE:NO proposal is necessary to allow them
    to do so. ...

I certainly think your intermediate proposal might be the right way to
gloss this messy issue with a minimum of incompatible change, but while
we're on the subject I feel I should point out that the issue of
interactive and the issue of batch, while strongly [inversely]
correlated in practice are not necessarily so strongly correlated in the
abstract. You could have batch applications which work on the terminal,
or even non-batch situations where it was important to see the output of
DESCRIBE without needing intervention.  The most irritating case is one
where the query gets asked on a window for which there is no way to
select the window to type to. Similarly, you could have situations where
data was going to a file and the query were still appropriate. So noticing
the interactiveness of the stream is one that is statistically less likely
to lead to trouble, but it is not, strictly, a real solution to the problem.

I keep falling back to what somebody once called "pitman's two-bit rule"
of language design -- it goes something like: if you have two bits of
info to represent, use at least two bits to do the representation. Since
interactiveness of the input argument and need for query are potentially
orthogonal, you can't get away with passing only one argument and using
it for both purposes without running into trouble some of the time. A
more robust solution would add a :DETAILED or :VERBOSE option to
DESCRIBE, which could be T, NIL, or :ASK.