issue COMPILE-FILE-SYMBOL-HANDLING, version 3

[Patrick Dussud <dussud@lucid.com>]

   From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
   Date: Tue, 18 Apr 89 14:33:20 MDT


   At last month's meeting, we agreed that compromising on some variant
   of proposal REQUIRE-CONSISTENCY was the only practical solution on
   this issue, but several people have indicated they think it's
   unacceptable to restrict IN-PACKAGE to being the first form in the
   file.  Here's a modified proposal that tries to get around that
   problem.

   Forum:		Compiler
   Issue:		COMPILE-FILE-SYMBOL-HANDLING
   References:	CLtL p. 182
		   Issue IN-PACKAGE-FUNCTIONALITY (passed)
		   Issue CONSTANT-COMPILABLE-TYPES (passed)
		   Issue DEFPACKAGE (passed)
   Category:	CHANGE/CLARIFICATION 
   Edit History:   V1, 01 Feb 1989, Sandra Loosemore
		   V2, 12 Mar 1989, Sandra Loosemore (discussion, error terms)
		   V3, 18 Apr 1989, Sandra Loosemore (new proposal)
   Status:		Ready for release


   Problem Description:

   It is not clear how COMPILE-FILE is supposed to specify to LOAD how
   symbols in the compiled file should be interned.  In particular, what
   happens if the value of *PACKAGE* is different at load-time than it
   was at compile-time, or if any of the packages referenced in the file
   are defined differently?

   There are two models currently being used to implement this behavior:

     (1) Symbols appearing in the output file produced by COMPILE-FILE
	 are qualified with package prefixes in the same way that PRINT
	 would qualify them.  Symbols that are accessible in *PACKAGE*
	 at compile-time are looked up in *PACKAGE* at load-time.  (This
	 is the "current-package" model.)

     (2) Symbols appearing in the output file produced by COMPILE-FILE
	 are always qualified with the name of their home package,
	 regardless of the value of *PACKAGE*.  (This is the
	 "home-package" model.)


   Proposal COMPILE-FILE-SYMBOL-HANDLING:NEW-REQUIRE-CONSISTENCY:

     In order to guarantee that compiled files can be loaded correctly,
     users must ensure that the packages referenced in the file are defined
     consistently at compile and load time.  Conforming Common Lisp programs
     must satisfy the following requirements:

     (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?

     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.

Patrick.