[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
issue COMPILE-FILE-SYMBOL-HANDLING, version 3
- To: firstname.lastname@example.org
- Subject: issue COMPILE-FILE-SYMBOL-HANDLING, version 3
- From: Patrick Dussud <email@example.com>
- Date: Fri, 21 Apr 89 09:04:02 PDT
- Cc: firstname.lastname@example.org, email@example.com
- In-reply-to: Sandra J Loosemore's message of Thu, 20 Apr 89 10:46:06 MDT <8904201646.AA07614@defun.utah.edu>
From: firstname.lastname@example.org (Sandra J Loosemore)
Date: Thu, 20 Apr 89 10:46:06 MDT
I don't think "load" is the right word here because it's an operation
on files, not forms. The forms in the file are executed as part of
loading, of course. Perhaps I can come up with some better wording on
this, though. I'll have to think about it.
I see your point. Maybe processed would convey what you want to say?
I disagree -- this paragraph is the key to the whole proposal. The
previous items are requirements for a program to be valid. This
paragraph says how valid programs behave. If we delete it, we will
still have no statement of how symbols referenced in the source code
for a file relate to the symbols in the compiled code for that file.
I do not believe what this paragraph is trying to say is incompatible
with the "current package" model because of item (2) -- if a symbol is
accessible in *PACKAGE* (and hence has no home package information),
the same symbol must also be accessible in the home package. Now that
I look over the exact wording here though, it does rather give the
impression that implementations must remember the home package.
Suppose I changed it to say:
...the interned symbols it references are found as if INTERN were
called at load time with two arguments....
That's much better.