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

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

    Date: Mon, 17 Oct 88 17:58:22 PDT
    From: Jon L White <jonl@lucid.com>

    ...
    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 is a current practice statement. Please note it.

    This doesn't work the same; namely, it forces a user to preface his files:
	    (cloe:in-package <mumble> ...)
    rather than:
	    (in-package <mumble> ...)

No. Our USER package uses CLOE, so (IN-PACKAGE ...) [unqualified] calls
CLOE:IN-PACKAGE.

There is a command you can run to say that you would prefer the system not
show you Cloe extensions, so there is no trouble getting the other behavior
for people who want it.

    That is, assuming that CLOE does the reasonable thing of reading the 
    IN-PACKAGE command from the USER package.

There are no restrictions in CLtL about what packages the USER package may use,
what symbols it may shadow, etc.

Anyway, the -important- thing is that LOAD is documented to rebind *PACKAGE*
to its current value. Hence, a safe portable program must -always- say
LISP:IN-PACKAGE (if that's what it intends) just in case the "current value"
of *PACKAGE* is a package which has shadowed IN-PACKAGE to be something which
means nothing like what it means in CLtL... eg, what if *PACKAGE* is the keyword
package when you call LOAD?

    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.

Nonsense. The user selects once at the beginning of his session whether he's
working with the Cloe extensions or not. From then on out, everything is
entirely consistent. In general, you have the problem that 

    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, ..."

I think there should be a portable way to get portable code (ie, the language
without extensions). I don't want to waste -any- time figuring out how people
get to system-dependent stuff. There's already an adequate mechanism for doing
that. And even if there weren't, an extension could be added in a system-dependent
way without wasting any CL designers' time. 

    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.

That's because that's what p183 of CLtL says they have to do!

    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.


I strongly disagree. You have no idea what's in USER. Besides, it's gratuitously
incompatible with existing programs, as is your suggestion to change the
meaning of MAKE-PACKAGE with no :USE argument.

    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.

The compiler committee had thought it through. The ammendment to that
proposal to which we agreed -- my addition of wording saying "to its current
value" -- was exactly to make it consistent with the documented behavior
of LOAD (because we believe most implementations already provide such
consistency).