[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue: MAKE-PACKAGE-USE-DEFAULT (version 1)
- To: firstname.lastname@example.org
- Subject: Issue: MAKE-PACKAGE-USE-DEFAULT (version 1)
- From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Mon, 17 Oct 88 21:40 EDT
- Cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.Stanford.EDU
- In-reply-to: <8810180058.AA05092@bhopal>
Date: Mon, 17 Oct 88 17:58:22 PDT
From: Jon L White <email@example.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> ...)
(in-package <mumble> ...)
No. Our USER package uses CLOE, so (IN-PACKAGE ...) [unqualified] calls
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
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