[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
CLARIFICATION: [italics]package arguments.
- To: firstname.lastname@example.org
- Subject: CLARIFICATION: [italics]package arguments.
- From: email@example.com (Jon L White)
- Date: Fri, 17 Apr 87 21:16:27 PDT
- Cc: firstname.lastname@example.org
- In-reply-to: email@example.com's message of Fri, 17 Apr 87 15:08:45 PDT
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
(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 --