Previous: Source Tree Structure, Up: Package and File Structure [Contents]
Goals: with the single exception of LISP, we want to be able to export from the package that the code lives in.
— These Implementation-dependent system-interface packages provide direct access to specific features available in the operating system environment, but hide details of how OS communication is done.
contains code that must know about the operating system environment: I/O, etc. Hides the operating system environment. Provides OS interface extensions such as print-directory, etc.
hides state and types used for system integration: package system, error system, streams (?), reader, printer. Also, hides the VM, in that we don’t export anything that reveals the VM interface. Contains code that needs to use the VM and SYSTEM interface, but is independent of OS and VM details. This code shouldn’t need to be changed in any port of CMU CL, but won’t work when plopped into an arbitrary CL. Uses SYSTEM, VM, EXTENSIONS. We export "hidden" symbols related to implementation of CL: setf-inverses, possibly some global variables.
The boundary between KERNEL and VM is fuzzy, but this fuzziness reflects the fuzziness in the definition of the VM. We can make the VM large, and bring everything inside, or we can make it small. Obviously, we want the VM to be as small as possible, subject to efficiency constraints. Pretty much all of the code in KERNEL could be put in VM. The issue is more what VM hides from KERNEL: VM knows about everything.
Originally, this package had all the system code in it. The current ideal is that this package should have no code in it, and only exist to export the standard interface. Note that the name has been changed by x3j13 to common-lisp.
contains code that any random user could have written: list operations, syntactic sugar macros. Uses only LISP, so code in EXTENSIONS is pure CL. Exports everything defined within that is useful elsewhere. This package doesn’t hide much, so it is relatively safe for users to use EXTENSIONS, since they aren’t getting anything they couldn’t have written themselves. Contrast this to KERNEL, which exports additional operations on CL’s primitive data structures: PACKAGE-INTERNAL-SYMBOL-COUNT, etc. Although some of the functionality exported from KERNEL could have been defined in CL, the kernel implementation is much more efficient because it knows about implementation internals. Currently this package contains only extensions to CL, but in the ideal scheme of things, it should contain the implementations of all CL functions that are in KERNEL (the library.)
hides information about the hardware and data structure representations. Contains all code that knows about this sort of thing: parts of the compiler, GC, etc. The bulk of the code is the compiler back-end. Exports useful things that are meaningful across all implementations, such as operations for examining compiled functions, system constants. Uses COMPILER and whatever else it wants. Actually, there are different machine-VM packages for each target implementation. VM is a nickname for whatever implementation we are currently targeting for.
hides the algorithms used to map Lisp semantics onto the operations supplied by the VM. Exports the mechanisms used for defining the VM. All the VM-independent code in the compiler, partially hiding the compiler intermediate representations. Uses KERNEL.
holds code that does direct execution of the compiler’s ICR. Uses KERNEL, COMPILER. Exports debugger interface to interpreted code.
presents a reasonable, unified interface to manipulation of the state of both compiled and interpreted code. (could be in KERNEL) Uses VM, INTERPRETER, EVAL, KERNEL.
holds the standard debugger, and exports the debugger
Previous: Source Tree Structure, Up: Package and File Structure [Contents]