Issue: MAKE-PACKAGE-USE-DEFAULT (version 1)

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

re: Many portable programs will be forced to put :USE "LISP" in where they
    do not currently specify. 

I claim this is not so [i.e. the "do not currently specify" part].  The 
relevant, unchallenged part of the proposal says:

    Cost to Users:

    In theory, every user porting code from one vendor to another would
    have to ensure that every package definition, via IN-PACKAGE or
    MAKE-PACKAGE, had an explicit :use list.  This is probably at most
    a 5-minute text editor search.  But in fact this imposition is moot,
    since virtually every such user has *already* supplied explicit
    :use lists; given the current practice, he has had no alternative.


re: Finally, under current practice, you ignored my remarks about Cloe so I'll
    repeat them. Cloe shadows MAKE-PACKAGE, IN-PACKAGE, etc. in the default
    package so that it offers the functionality you desire in a way that is
    not incompatible to Lisp. I would recommend that you do the same.
     LISP:MAKE-PACKAGE name &KEY nicknames (USE "LISP")
     CLOE:MAKE-PACKAGE name &KEY nicknames (USE "CLOE")
    Once you've chosen a package to work from, all calls to an unqualified
    MAKE-PACKAGE do the thing that is natural for that initial package.

This doesn't work the same; namely, it forces a user to preface his files:
        (cloe:in-package <mumble> ...)
rather than:
        (in-package <mumble> ...)
That is, assuming that CLOE does the reasonable thing of reading the 
IN-PACKAGE command from the USER package.  If you have some other
default package, then that itself is an imposition on at least the
same order of magnitude as the proposal for MAKE-PACKAGE-USE-DEFAULT.

I see MAKE-PACKAGE-USE-DEFAULT:IMPLEMENTATION-DEPENDENT; as the lesser
of several evils.  As moon said [in msg of  Tue, 11 Oct 88 12:58 EDT]
    "... the issue is whether the default should
     be a portable way to get the local extensions, or a portable way to
     get the portable language without the extensions.  I think either of
     those choices is portable and reasonable, it just depends on what you
     want to make easier, ..."

Now, there may be a separate issue we haven't addressed yet -- just
what package is current when you load a file?  A "good style" program
will have an IN-PACKAGE command as the first executable form in the
file [or, a DEFPACKAGE followed by an IN-PACKAGE ?].  The question is,
how do you read the IN-PACKAGE itself?   Unfortunately, all 
implementations I've examined, including Lucid's, just leave you in 
the current package.  I believe the "reasonable" thing to do is to 
rebind *package* to USER; the expectation, of course, is that the current
package will immediately be changed via IN-PACKAGE.

The same issue holds with respect to the CL-Compiler committee's issue
about what package you start out in when you compile-file a file.  I
fear that, at the recent x3j13 meeting, we too easily assented to a 
rebinding of *package* to itself, precisely because we hadn't thought
through this "separate issue" before.



-- JonL --