[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Issue: DESCRIBE-INTERACTIVE (Version 3)
- To: "David A. Moon" <Moon%STONY-BROOK.SCRC.Symbolics.COM@multimax>
- Subject: Re: Issue: DESCRIBE-INTERACTIVE (Version 3)
- From: Dan L. Pierson <pierson%mist@multimax.ARPA>
- Date: Mon, 31 Oct 88 13:21:15 EST
- Cc: cl-cleanup%sail.stanford.edu@multimax
- In-reply-to: Your message of Wed, 26 Oct 88 22:45:00 -0400. <19881027024541.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
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
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.