[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: issue COMPILE-FILE-SYMBOL-HANDLING, version 3
- To: Patrick Dussud <firstname.lastname@example.org>
- Subject: Re: issue COMPILE-FILE-SYMBOL-HANDLING, version 3
- From: email@example.com (Sandra J Loosemore)
- Date: Thu, 20 Apr 89 10:46:06 MDT
- Cc: firstname.lastname@example.org, email@example.com
- In-reply-to: Patrick Dussud <firstname.lastname@example.org>, Thu, 20 Apr 89 09:25:06 PDT
> Date: Thu, 20 Apr 89 09:25:06 PDT
> From: Patrick Dussud <email@example.com>
> (1) The value of *PACKAGE* when a top-level form in the file is processed
> by COMPILE-FILE must be the same as the value of *PACKAGE* when the
> code corresponding to that top-level form in the compiled file is
> executed. In particular:
> You mean loaded instead of executed right?
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.
> If all of these conditions hold, then when a compiled file is
> loaded, the interned symbols it references are found by calling
> INTERN at load time with two arguments, the name of the symbol and
> the package with the same name as the compile-time symbol's home
> package. If no such package exists, an error is signalled.
> I think this should be removed. It clearly is overspecification. We should
> specify behaviour of conforming programs. You are trying to describe the
> behavior of an implementation. Besides, this is incompatible with the current
> package practice, because they lose the home package when they dump.
> I will be perfectly happy with just the requirement 1 and 2.
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....