Issue: DEFPACKAGE (version 2)

[Jon L White <jonl@lucid.com>]

re: 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 ...

(version 2) actually says "symbol-name" rather than "symbol"; I think moon
agreed to this in a message last May.


re: . . . allowing a user to type foo::bar in a defpackage
    is no worse than allowing it in some random program.  

Well, damage is often in the eye of the beholder, but DEFPACKAGE is a bit 
of a "lever" in that if you don't need colon qualifications in it, you can
generally say that you don't need it in your file at all.  Let's grant for 
the moment that single-colon qualifiers in files are bad; so bad that even 
just *one* of them can be disastrous (as another part of your msg suggests).
Then with a proper use of DEFPACKAGE, you can almost always "import" etc the
needed symbols so that they are available unqualified; but if you can't even 
name them in order to import them, you've completely lost "the battle of the
colons".  Thus the whole issue swings on the optionality of symbols in the 
options to DEFPACKAGE.


re: 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 ...

Bill, are you sure you've been reading (version 2) and not (version 1)?  This
point was also recently changed; the specification of :IMPORT-FROM says:

  (:IMPORT-FROM {(package-name {symbol-name}*)}*)
  (:IMPORT-FROM package-name {symbol-name}*)
	  Find the specified symbols in the specified packages and import
	  them into the package being defined.  . . .  In no case will 
	  symbols be created in a package other than the one being defined; 
	  a continuable error is signalled if no symbol is accessible for 
	  one of the names in its corresponding "from" package.  ...


re: (1) What, exactly, does defpackage do?  ... Does it do also do an 
    in-package?  Does it return the package as value?

Good point.  It's probably arbitrary, but should be spelled out.


re: (2) What happens when the package already exists?  I think the union 
        method is best, but it may also require more explaining.

My msg of  Date: Wed, 28 Sep 88 14:50:29 PDT  proposed three alternatives;
your suggestion of "union" is probably similar to alternative (3), which
KMP also favored.  I see that we need some discusson on this point of what
it means to "resolve" an existing package with a candidate new definition.
Got any ideas?



-- JonL --