Issue: MAKE-PACKAGE-USE-DEFAULT (split from PACKAGE-CLUTTER)

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

re: But then I get to issues like this, where if you write a simple program 
    that says
       (in-package "FROB") 
       (defun draw-line (x y) ...)
    that when they go to port it to Vendor y, they find out that their simple
    program crashes the graphics package because draw-line now has the wrong
    arguments. "I meant FROB:DRAW-LINE, not some LU-GRAPHICS:DRAW-LINE."?

First, the 'in-package' statement doesn't necessarily define the package,
and hence one can't assume a default :use list.  

Probably one of the more confusing bugs that users fall into is having two 
slightly different package creation forms in two different files belonging 
to the same package.  Say:
    (in-package "FROB" :use '(:lisp :holistics))
in the first file, and
    (in-package "FROB")
in the second.  IN-PACKAGE as currently defined is not supposed to "warn" 
you if the package doesn't already exist, or if it exists with components 
different from what you specified.  You simply lose if you process the 
second file first.

[Incidentally, this brings up the fact that the only utility of a DEFPACKAGE 
proposal is that it tends to focus on one place, and one place only, where a 
package can be defined.  The proposal adds absolutely no functionality not 
currently available with the "7 extremely randoms" and 'eval-when' -- it 
merely focuses the user's attention.]


Second -- as mentioned in prior mail -- those currently porting from 
vendor to vendor will *never* allow the :use argument to MAKE-PACKAGE to 
be defaulted.  This good practice could be encouraged by removing from the
standard any requirement about what the default will be.  Those involved in 
*converting* code written for one vendor's Lisp to run in another vendor's 
face a different problem, namely how to reconcile the names they have used 
with those "available" under the other vendor [frequently, they even
aren't concerned with being super-portable, especially when it comes
to windows and graphics capabilities, since there is no standard yet
in those realms.]

The references to the portability of C programs, and to the difficulty
of porting CL programs, seems to be completely ignorant of the horrible
problem in porting between one vendor's Unix library and another's.  As 
if C were merely a "language" with no library support needed!  But in fact
CLtL is not only a specification for the hard-core language, but that also
for the greater part of the runtime-library.


At any rate, portabililty is not sacrificed in the least when it is defined
as "portable programs must supply the :use argument to MAKE-PACKAGE and
friends."




-- JonL --