Plan for dealing with PACKAGE-SYSTEM related problems on the LAMBDA and the FALCON.


   The problem:
	The previous administration has introduced numerous extraneous packages into
our current software system (such as CONS:, etc etc).  It is generally agreed that
all of them except the HW (hardware) package should be eliminated, other things being
equal, the sooner the better.  However, simply eliminating them would cause a number
of problems since various clashes (both within the Falcon system and between the
Falcon system and the lambda) would occur.  In quite a few cases, actual differences
in functionality (as opposed to merely portability) issues are involved.
Consistant with our long standing general strategy to freeze the FLEABIT system 
as much as possible, it would be desirable to avoid getting bogged down in 
revamping the internals of FLEABIT if possible.

	A primary consideration when moving list structure between computer software
environments is the existance of a simple and reliable tranformation (hopefully the identity transformation)
between corresponding packages and symbols of those environments.  If this
is not true, the lists which read in EQUAL on one system might not be EQUAL on the other, etc.

	On the Falcon, it is desireable to introduce as little as possible of the
extraneous multiple-package lossage.  On the other hand, it is probably not feasible to
eliminate it completely unless the corresponding thing were done on the Lambda,
which, as discussed above, is at least a lot of work.  By initializing things correctly
on the FALCON, however, it should be possible to have current FLEABIT-compiled runtime
code continue to work and also to load in the LAMBDA software in a suitable package environment.


	The current package structure of the FLEABIT system on the lambda
is proven to "work" (at least enuf to do mega-boot, etc).  It is proposed that
the LAMBDA component of the FLEABIT software remain substantually "as is".  

	However, the current package environment on the FALCON will need some work
in any case.   

	One complicating factor is that fact that certain files are expected to be compiled
for both machines.  Having common files could be a good idea if it really reduced the total diversity of code
necessary to implement the system. Unfortunately, as it is currently implemented, it turns
out to be a really bad idea because these files are actually processed in quite different
ways by the two systems.  (ie, a hardware instruction on one system versus a funny subroutine
on the LAMBDA).  However, we are stuck with this.


	A drastic step would be the elmination of the "package-munger" currently in
the FLEABIT FASDUMP.  (Implemented as the function GET-SYMBOL-PACKAGE-NAME in "K-SYS: K;NEW-FASDUMP").
This function in its current form directly violates the "simple transformation" requirement, so
it definitely has to go if there is to be any hope of achieving that goal.  Unfortunately, since
it happens at compile time, any change will mean recompiling the entire environment if it is to
"take".	  
** revision 9/3/88 **
	William has proposed not flushing the package-munger.  If it were the case that it only
"munged" between packages which were destined to resolve to the same package anyway if the 
full package system were available, then it would not really be messing things up.  The problem
with this argument is that (1) that doesnt seem to be the case as stands and (2) if it was, why
would it be necessary since the symbols in question should have resolved uniquely when read into the
LAMBDA system.  Another point though, is that the package-munger used only by the FLEABIT fasdumper,
and not by the cross-compiler fast dumper.  So, if it serves to make bootstrap environment come up
in an acceptable state, why disturb it since it is not really involved in anything from that point
on.  This is a dangerous type of argument in a sense, on the other hand, if we understand clearly
what we are doing it may be acceptable
**

	How the FLEABIT-compiled system comes up.

   The FLEABIT-COMPILED system bootstraps itself
in a fairly unusual way, which has some implications on how the package structure gets established.
The FLEABIT cold-load generator has no knowledge of list structure whatsoever!  Therefore the cold
load actually starts and runs with no symbols or symbol-structure at all.  Soon after it starts,
however, it does a download of linkage information followed by a download of the "warm" files,
which operations create symbols and symbol structure, despite the fact the the full package mechanism
is not yet available.  Symbols created during the process are placed on a single list, the *WARM-SYMBOLS*
list, and are "uniquified" only by pure identnity of [print-string,package-string] (there is as yet
no package structure in existance yet).  This is inheritly quite risky, since potentially incorrectly
distinct symbols could be created during this phase.

	The Lambda system bootstrapping process avoids most of these risks because the cold load
generator DOES have a substantual SYMBOL and LIST structure component and because INTERN and associated
functions are part of the cold load itself.  Thus, the package structure is created immediately
after the cold load comes up and before any files are loaded.  This also means that no new symbols
can be created until the package structure exists and is fully functioning, avoiding possible lossage.

	Even though the FLEABIT-compiled system is inheritly inferior in structure in this respect,
as are so many aspects of the FLEABIT system, I think it can serve our current purpose, which is to
bootstrap the LAMBDA system, if we are careful.  However, there is no doubt that until we eliminate it
entirely we will continue to be exposed to real risks of lost time due to various screwups.

	Identity of symbols on the LAMBDA versus on the FALCON

	The simple transformation goal implies that if two [symbol-pname, package-name] combinations
resolve to the same symbol on the LAMBDA (for example) they must also do so on the FALCON.
Since there is an existance proof (on the LAMBDA) that the LAMBDA package structure can co-exist
with the FLEABIT one, it must be possible to adhere to the identity strictly and create a working
environment.   Maybe this is even the best course, although it is tempting to engage in a certain
"cheating" on the Falcon.  For example, on the LAMBDA we have CONS:CAR and GLOBAL:CAR as two distinct
symbols.  It would not be fatal to have two on the FALCON also, but it seems unnecessary since
the whole idea of having two was a bad idea in the first place.  In the case of CAR on the Falcon
the problem could be bypassed by simply interning a single CAR in ALL of the relavent packages
(GLOBAL: and CONS:) for example.  Then, everything gets read in correctly, whether it is old or
"FLEABIT compiled" code with CONS: or LAMBDA code with GLOBAL:, etc.  The problem comes where
there is actually clashing functionality, expecially within the FLEABIT system.  These represent
cases where work has to be done to figure out which functionality we really want and either delete
the other or rename all calls to it to be something else, etc.


	What we actually do:

	(1)   incorporate info which is currently in the pkg-definition into the FALCON package
		This should pretty much deal with all FLEABIT-LAMBDA symbol "problems"
		(-- accomplished 9/3/88)
	(2)   incorporate info re lambda-related symbols in sys:cold;global, sys:cold;lisp and
		sys:cold;system into the falcon package structure. This should take a few days
		at most.