Symbols in compiled files, and Issues IN-PACKAGE-FUNCTIONALITY & CONSTANT-COMPILABLE-TYPES

[Jon L White <jonl@lucid.com>]

I haven't forgotten about the following promise; but I will have to
postpone more details for another two weeks or so.  Basically, I
don't believe we have anything to gain at this point in trying to 
standardize the faslout package-qualification algorithm; this is 
notwithstanding that standardizing PRINT output, as an interchange
format, is an absolute requirement [even though READ-of-PRINT will
likely be even more information losing than loading in a compiled file!]

-- JonL --

    Date: Tue, 31 Jan 89 05:05:58 PST
    From: Jon L White <jonl>
    To: sandra%defun@cs.utah.edu, Moon@STONY-BROOK.SCRC.Symbolics.COM
    Cc: CL-Compiler@SAIL.STANFORD.EDU,
	    Common-Lisp-Implementors@STONY-BROOK.SCRC.Symbolics.COM
    In-Reply-To: Sandra J Loosemore's message of Wed, 25 Jan 89 09:58:52 MST <8901251658.AA20469@defun.utah.edu>
    Subject: Issue: CONSTANT-COMPILABLE-TYPES (Version 5)

    . . .

    I intend to reply more fully to moon's "amendment" to your
    IN-PACKAGE-FUNCTIONALITY proposal; and in that reply, I will detail
    why it is the case that compiling out symbols should *not* be
    specified to be any of the following three simple algorithms:
       (1) fully-package qualified
       (2) just like PRINT
       (3) moon's minor variation on PRINT
    That response will make it more clear why having two IN-PACKAGEs in a
    single file ought to be allowable (although the Lucid documentation 
    warns against it for reasons of style).  Anyone on this mailing list who 
    doesn't receive cl-cleanup mail, but who would like to see this reply, 
    should ask me privately for a copy.  The essense of this reply will
    be that it is useful for an implementation to allow as many gratuitous
    variations in the package setup between compile-time and load-time 
    readings, provided that the source file does the same thing in each 
    variation.

    . . .