Clearly non-controversial

[Skef Wholey <Wholey@CMU-CS-C.ARPA>]

    From: brown at DEC-HUDSON
    Re:   Clearly non-controversial

     DELETE-SETF-METHOD access-fn				[function]
      Removes the update form associated with the symbol access-fn.
      The access function can no longer be used as generalized
      variable.

How about UN-DEFTYPE and UN-DEFSTRUCT and UN-DEFCONSTANT and so on?  All of
these would be useful (for the same reason as DELETE-SETF-METHOD is useful --
one is really screwed if there's no way to undo a wrong one).  Coming up with a
list of all such things is a non-trivial task, and including one without all
others could be silly.  On the other hand, adding a dozen undo functions to the
language, however simple, might stir up some controversy.  I don't know the
right way to go here.  Perhaps implementors might include information on how to
undo these things in their red pages.  Undoing functions could conceivably be
treated as "user interface", since they aren't likely to appear in programs.

     HASH-TABLE-REHASH-SIZE  hash-table			[function]
     HASH-TABLE-REHASH-TRESHOLD  hash-table			[function]
     HASH-TABLE-SIZE  hash-table				[function]
     HASH-TABLE-TEST  hash-table				[function]
      These functions return the values that were specified when
      the hash-table was created.

When it was created? How about the current (possibly after rehashing) values?
Was your above description a thinko?  Could the rehash parameters be set with
SETF?  [Rambling ideas: That could be useful for growing hash tables in some
non-linear, non-exponential fashion.  Maybe :REHASH-SIZE could also be a
function, in which case it takes an integer (the old size) and returns an
integer (the new size).  :REHASH-THRESHOLD could likewise be a two-arg
predicate.  This would let you rehash hash tables every Tuesday, for example.]

     DELETE-PACKAGE	package					[function]
      Uninterns all the symbols interned in package, deletes the package,
      and unuses all packages it uses.  An error is signaled if the 
      package is used by any other package.

Yes, that's definitely a good thing to have.  Hint for programmers living 
without this: use Rename-Package to get rid of the bogus package.
          
    (This list used to contain TERMINALP which returned T if its
     argument (string, pathname, etc.) was an "interactive terminal".
     I think this function would be useful, but decided I was unable
     to define what a terminal is, so removed it.)

I don't think all implementations could accurately answer the "is this stream
backed by a user" question.  I guess a second value indicating whether or not
the answer was determined for sure would have to be returned.  What would you
use such a thing for?  I can only think of things that aren't really good
things for supposedly portable programs to do.  In line with the other
stream type predicate functions (e.g. Input-Stream-P), perhaps the name could
be Interactive-Stream-P?

--Skef