When is a package name equivalent to a package?

[David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>]

    Date: Wed, 24 Apr 1985  22:04 EST
    From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>

        From: Moon
	I think the manual is quite clear.

	p.183 requires that the value of *package* be a package.

	p.182 specifies that certain functions, including INTERN, shall accept strings
	and symbols in place of packages.  As is unfortunately typical of the CLM,
	this specification is not repeated in the documentation of each of the affected
	functions, so it's quite easy to overlook.

    Are we looking at the same page 182?   Where does it say that?  In the
    last paragraph it says that "Any argument described as a PACKAGE NAME
    may be either a string or a symbol."  Is that waht you're thinking of?
    Intern takes a package argument, but says nothing about taking a package
    name instead.

You're absolutely right.  I didn't read the manual carefully enough and missed
the word "name" after "package", especially since two sentences earlier in the
same paragraoh it was talking about arguments named @I[package].  The wording
could use some improvement here, I think.

In fact page 182, now that I am reading it carefully, says nothing about
what values are legal to pass to an argument named package.

Now I have to ask if there is any significance to the fact that the argument
to FIND-PACKAGE is called name rather than package-name.

Obviously I should withdraw the first sentence of my earlier message!

Our implementation of these functions (INTERN, USE-PACKAGE, IMPORT, etc.)
accepts a package name as an argument where a package is required.  It seems
natural, and doesn't cost anything if you were doing error-checking anyway (and
blithely assuming that the argument is a package seems extra-dangerous here!).
However, I won't advocate that every implementation be required to accept a
package name in place of a package.