[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue: MAKE-PACKAGE-USE-DEFAULT (version 1)
- To: KMP@STONY-BROOK.SCRC.Symbolics.COM
- Subject: Issue: MAKE-PACKAGE-USE-DEFAULT (version 1)
- From: Jon L White <firstname.lastname@example.org>
- Date: Mon, 17 Oct 88 17:58:22 PDT
- Cc: CL-Cleanup@SAIL.Stanford.EDU
- In-reply-to: Kent M Pitman's message of Sat, 8 Oct 88 23:04 EDT <881008230447.5.KMP@BOBOLINK.SCRC.Symbolics.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> ...)
(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 --