package.mss.108

[Scott E. Fahlman <Fahlman@CMU-CS-C>]

Dave,

I've got no problem with any of your "small" issues.  I'll make all
those changes.

The use of a symbol argument (not a string) in FIND-ALL-SYMBOLS was
deliberate.  It didn't seem to me that interning a symbol (internally in
the user package or wherever the user is typing) was something
particularly to be avoided.  With a string, you get all the issues of
case, and with a symbol argument you automatically get the intuitive
thing.  But I've got no real problem with allowing either a string or a
symbol here.

On the two larger issues you raise, I think we have some fundamental
disagreements.

    Medium:

    I'm not completely happy with declare-package and the :export keyword.  I
    don't like the idea of package A exporting symbols from package B; what if
    there is a typographical error, a conceptual mistake, or an obsolete symbol
    in the list supplied by package A, which is a duplicate of package B's
    list?

The symbols that are put into B by a DECLARE-PACKAGE statement in file A
are declared in an export list, and you have to be careful when typing
export lists.  There is no reason to believe that B is going to be
sloppier than A.

There is, of course, the problem of these lists getting out of synch,
but I think that this problem is not likely to be a serious one, since
the list in B is supposed to be a subset of the list in A -- B just
declares those symbols from A that it actually uses.  If A gets
augmented, that causes no problem for B.  If something that B uses gets
taken out of A (rare compared to augmentation), you're going to end up
with an undefined function or unbound symbol bug, but that is
unavoidable under any scheme.  You also end up with a stray external
symbol in package B because of the declaration in A, but the chances
that this stray symbol is really going to screw anyone seem pretty small
to me.

So you have an error (getting out of synch) that COULD occur in a rare
situation (removing an external symbol from some package's interface),
and that is unlikely to cause trouble if it does occur.

I don't see how the "owner vs. user" error checking that you advocate
can work unless you require that the exporting package be loaded before
the using package (in which case the user doesn't need to declare the
package at all).  In files that use external symbols from one another, all
of the exports would have to be done before either file is loaded -- the
package creation and exporting would have to be split into a separate
file.  Admittedly this is safer, but it is also a LOT less convenient.
I just don't think that the danger of an occasional stray external, as
described above, is worth that sort of restriction.  Unless I'm
overlooking some more common source of errors or you have some way to do
the consistency checking without restricting load-order, I feel strongly
that we should keep PACKAGE-DECLARE the way it is.

    Large:

    In your writeup, name clashes are only discussed under IMPORT.  Name
    clashes should be given their own discussion section, and the following
    functions should be required to check for name clashes: EXPORT, IMPORT,
    USE-PACKAGE, INCLUDE-PACKAGE, and the implicit calls to those functions
    from MAKE-PACKAGE, DECLARE-PACKAGE, and IN-PACKAGE.  When the externals of
    a package are altered, the check for name clashes must extend to all
    packages that inherit from that package (via either use or include).  A
    name clash occurs when there is an attempt to make a symbol accessible in a
    package with the same name as a distinct symbol already accessible in that
    package, except when shadowing has been used to declare the user's
    intentions (there is a symbol already accessible in the package, with
    the same name, that was mentioned by SHADOW).  When a name clash occurs,
    a correctable error is signalled.

Well, there are two cases here.  I have no strong objection to making
IMPORT, USE-PACKAGE, and INCLUDE-PACKAGE look around when they are
called and cause a correctable error if some symbol is about to be
shadowed.  We would have to add some sort of :INTENTIONALLY-SHADOWING
list to these forms so that the error can be suppressed for specific
known clashes, but that's OK.  I also have no objection to having EXPORT
look at its package's ancestors and signal an error if the
newly-exported symbol would shadow an inherited one.

What I object to very strongly (I think) is the notion that any of these
operations, when performed in package X, have to worry about what's
going on down in the descendant packages.  It's tricky enough to make
this work looking up the tree, and I think it's impossible to sort it
out looking down.  All sorts of things might have been shadowed and moved
around by explicit agreement, and trying to decide after the fact what
is to be an error would be impossible.

Once again, we are talking about adding a LOT of conceptual hair to
handle a problem that will seldom occur and that will probably not screw
anyone if it does occur.  It will very rarely be the case that you want
to mess with the external symbols of a package after other packages have
begun using it, and even if you do, it is unlikely to cause any trouble.
If (EXPORT FOO) is called in package X and package Y, which uses X, has
no FOO of its own, there's no problem.  If Y does have a FOO, it will
continue to use its own FOO, and things are no worse than before.  If Y
includes X (relatively rare), it is just the same, except that Y's
descendants now see X:FOO, while Y sees its own internal FOO.  But the
descendants couldn't have wanted to get Y's internal FOO, so this is OK.
I'm sure there's some way to construct a bug out of all this, but it
doesn't look to me like it's going to be a problem for real users.

-- Scott