[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue: DEFPACKAGE (version 3)
- To: Gregor.pa@Xerox.COM
- Subject: Issue: DEFPACKAGE (version 3)
- From: Jon L White <firstname.lastname@example.org>
- Date: Wed, 28 Sep 88 13:19:55 PDT
- Cc: Moon@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@Sail.stanford.edu
- In-reply-to: Gregor.pa@Xerox.COM's message of Wed, 28 Sep 88 09:21 PDT <19880928162127.8.GREGOR@PORTNOY.parc.xerox.com>
re: I think that at least IN-PACKAGE should not accept these options, and
should be used for selection only. The reason is the same as the one
for adding DEFPACKAGE. If you do this to IN-PACKAGE, people will end
up making the same mistake of using in-package with different arguments
in different files of their program.
The relevant section of the proposal (version 3) reads:
Also expand MAKE-PACKAGE (and IN-PACKAGE, unless the cleanup Issue
IN-PACKAGE-FUNCTIONALITY is adopted) to take all the same keyword
arguments as DEFPACKAGE, for consistency.
As moon rightly points out, we have to address the pull-back of
IN-PACKAGE separately, since it is a serious incompatible change.
[Note that I'm agreeing with you -- I just want to move the discussion
about it into the pre-existing Cleanup issue.]
re: Also, wherever it currently takes a symbol or a symbol-name (string), it
should just take a string. . . .
I'd certainly be happy with that, but my impression is that moon and kmp
feel it is important to be able to use symbols just for their print-name;
the issue being that case-conversion happens automatically for symbols,
but doesn't for strings. Given the option to use strings everywhere, and
given implementation techniques that permit the compiler to evade package
issues (in the compiled output for a DEFPACKAGE), this admission to "lazy
typing" seems harmless. Note also that many users have discovered the
wonderous insensitivity to package problems that the notations :FOO and
re: . . . In systems which use
a "structure" editor, forms which take symbols as their argument,
and then change the print-name of those symbols, cause all sorts of
problems. So, at least the import options will cause problems for
There is no common-lisp capability to "change the print-name" of symbols.
This DEFPACKAGE proposal doesn't suggest that, so if you think it implied
it somehow, maybe you could point out the confusing phrases.
-- JonL --