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 of a simple and reliable tranformation (hopefully the identity transformation)
should exist between a corresponding packages and symbols 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 as possible.  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 body of software remain substantually "as is".  

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

	The most drastic step will be the near 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 happenes at compile time, any change will mean recompiling the entire environment if it is to
"take".

	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 idenitity (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.  Another consequence is that no new symbols
can be created until the package structure exists and is fully functioning.

	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.