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. One complicating factor is that fact that certain files expected to be compiled for both machines. This 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 was in the two systems. (ie, a hardware instruction on one system versus a funny subroutine on the LAMBDA). However, we are stuck with this. 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. 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. This 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 compatible" 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.