Re: Issue: DEFPACKAGE (version 2)

[vanMelle.pa@Xerox.COM]

I strongly agree with JonL on point one, that it is important that the spec
permit strings in all the places that currently say "symbol" (except, of course,
:import and :shadowing-import).  I don't want to be forced to use a form that
has a side effect of interning random symbols that I'm then going to discard.
As a simple example, the following sequence:

	(in-package 'user)
	(defpackage foo (:export bar baz))
	(use-package 'foo)

will complain that foo:bar conflicts with user::bar.  Environments with
residential structure editors probably feel even more strongly of the need for
strings.  I take it there was no serious disagreement on this.

JonL's second point, that :import and :shadowing-import should be flushed, is
less clear.  I agree with Moon that allowing a user to type foo::bar in a
defpackage is no worse than allowing it in some random program.  I also agree
with JonL that :[shadowing-]import is of relatively little utility given the
existence of :[shadowing-]import-from.  I see it mainly as a shorthand (and a
perfectly "safe" one in the case of external symbols), though not one that saves
more than typing a couple of parentheses.  Here are a couple other arguments for
getting rid of :[shadowing-]import on aesthetic grounds:

(1) It's the only option that really does require symbols.  If you omit it, you
can explain the various options solely in terms of pnames, without constantly
saying "if symbol, only its name is used".  JonL alludes to this.

(2) It's unusable altogether in residential environments unless the environment
goes to special effort to be careful.  E.g., if I read in the form

	(defpackage foo (:import window:bar))

and later print it out in the foo package, it comes out as

	(defpackage foo (:import bar))

which, of course, is not what I had in mind.

At any rate, the spec really should spell out what :import-from does if the
specified symbol is not accessible in the package.  I.e., does it behave like
(:import package::name), thus creating the symbol anyway, or like (or
(find-symbol name package) (error ...)).

By the way, there are a couple things missing from the proposal that really need
to be stated somewhere, though I doubt any of them are difficult to answer:

(1) What, exactly, does defpackage do?  Yes, it creates the package according to
the specified options.  Does it do also do an in-package?  Does it return the
package as value?

(2) What happens when the package already exists?  Nothing?  Overrides previous
options?  "Union" of both?  I think the union method is best, but it may also
require more explaining.

	Bill