CLARIFICATION: [italics]package arguments.

[edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)]

Somewhere between 1 year ago and 2 years ago, I sent out a proposal to this 
list suggesting that the package functions of CLtL section 11.7 fall into
four categories:
  (1) those whose argument is documented as "must be a package";
  (2) those whose argument is documented as "a package";
  (3) those whose argument is documented as a "name" of (or for) a package;
  (4) all the rest.
Contrary to what John Diamant suggested, I think that very few functions
fall into category (1).  The vast majority seem to be in category (2).

Both Symbolics and Lucid apparently, independently, made a decision to 
interpret the documentation of category (2) to mean that any argument 
reasonably coercible to a package would in fact be so coerced.  That is, 
if the documentation goes out of its way to say "must be a package" for 
some functions, but doesn't do so for others, then it must be that the 
latter ones can be more generous in accepting alternate forms.

This implies, for example, that a string or symbol could be supplied as 
the "pacakge" argument to UNINTERN; but the argument to PACKAGE-NICKNAMES
can only be of type package, because it "must be a packge".

There wasn't a lot of discussion back then about these points -- certainly
there was no serious objection to them.  Probably the HP folks weren't
receiving the mail then?

-- JonL --