Issue: DEFPACKAGE (Version 4)

[Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>]

I have some (mostly non-technical) wording gripes which I think should
be made for clarity...

 - Don't refer to uppercase being "normally used". It depends on
   the application, etc. Just refer the user to INTERN.

 - Don't refer to "inheriting" in the description of :USE.
   Refer to USE-PACKAGE. Similarly, :SHADOW should refer to
   SHADOW, etc. After all, we've gone to considerable trouble
   to explain each of these concepts and we can't afford to have
   some bit of vague wording accidentally bind us into an
   inconsistency here. It is easier and more correct to simply
   say exactly what primitive these are giving us access to.

 - Rather than say what happens last,etc just say these will happen
   in an order that makes it all work if it's possible to make work.
   One of the major flaws of the ``put in seven...'' slogan is that
   it is not always possible to win that way -- it's only a rule of
   thumb and sometimes you have to use another ordering. DEFPACKAGE
   should be capable of constructing a correct ordering regardless
   of what order the user uses.

 - It's hard to tell if the comment in the examples is intended as
   general advice to people about how they should use DEFPACKAGE
   or a comment about what's going on in this particular DEFPACKAGE.
   It's obvious once you see the next test, but I think some fixing
   up should be done to avoid initial confusion. In fact, I might
   invert the order of the examples.

 - Also, I'd show the examples in lower case (with uppercase strings,
   of course) to emphasize the uppercasing feature of symbols that
   people seem so hooked on. Also, that would make it clear (by
   contrast) that the case of strings had to be uppercase and was
   not just accidentally matching the surrounding code.

 - I'm not a big fan of permitting the package name itself (the
   cadr of the DEFPACKAGE form) to be a string. That interacts badly
   with our editor (and many others I know of). But maybe that just
   means we should fix our editor. I dunno. I'd prefer people just
   put the package name in the keyword package.

 - In the Discussion, the remark about "The macroexpansion of
   DEFPACKAGE should be permitted to canonicalize into the ..."
   appears to belong elsewhere in the proposal. If it's `just an
   idea,' and not intended as part of the proposal, it should say
   so very clearly.
   Ditto for "Additional options might be present..."
   and "Frequently additional implementation-dependent..."