[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue: DEFPACKAGE (version 2)
- To: Moon@stony-brook.scrc.symbolics.com
- Subject: Issue: DEFPACKAGE (version 2)
- From: Jon L White <email@example.com>
- Date: Thu, 26 May 88 20:50:49 PDT
- Cc: CL-Cleanup@sail.stanford.edu
- In-reply-to: David A. Moon's message of Tue, 24 May 88 16:55 EDT <19880524205536.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
re: None of this addresses my comment. If the user insists on referencing a
non-exported symbol of the ULUZ package, what is the difference between
referencing (and hence creating) that symbol while reading an argument
to the :IMPORT option, and referencing (and hence creating) that symbol
while obeying the :IMPORT-FROM option?
I think you must have made this comment before reading the rest of my note
that you are replying to.
re: Okay, you're proposing that :IMPORT-FROM be changed to do something
different from any of the previous proposals, namely to call
FIND-SYMBOL instead of INTERN or the secret version of INTERN that
single-colon uses. I wish you had come right out and said so.
The situation is not quite so simple as that. I do favor altering the action
of :IMPORT-FROM in the way you deduce, since that would afford a much greater
measure of package integrity than is now common practice. However, I
*strongly* favor removing the requirement for symbols, even if we can't
agree on the first alteration just mentioned. The reason why this latter
semi-proposal affords a difference over doing nothing is two-fold:
(1) Certain kinds of non-EVAL file processors may be able to read this
form without evaluating it (cross-reference programs come to mind);
thus reading in the form with symbols in it "damages" the ULUZ package
in a way that "processing" alone would not.
(2) Many more soure-file/compile-file incompatibilities can easily be
turned up when the source-file has double-colon qualifications in
it. Thus apart from any evaluaton action of the defpackage form,
there is a possibility that compiled form of the file has different,
and ocasionlly much worse, side effects than the source file.
(DEFPACKAGE "FOO" (:IMPORT 'uluz::bunkie))
Compiled-file: [actions, more or less]
1. intern DEFPACKAGE in current package [probably inherit from CL]
2. make string "FOO"
3. intern BUNKIE in what package????? depends on how that symbol
was accessible at compile time. The fact that the user specified
it as uluz::bunkie is completely and totally lost after the source
code has been read-in!
4. intern IMPORT in the keyword package
5. call EVAL on cons'd-up form
In fact, the original motivation that caused me to start discussing a
defpackage months and months ago was the frequency at which "vanilla"
code can be read-in differently after being compiled [differently, because
of the information-losing property of double-colon format]. So even if
:IMPORT-FROM were to continue in its present (Symbolics) semantics, it would
still be of some benefit to use strings as args rather than symbols, in order
to prevent the occurance of obscure source/compiled-file differences.
-- JonL --