System structure and interface separation

The BlackBox subsystem named "System" contains the basic modules of the BlackBox system. Most of the modules are portable but some are not. The portability of the modules is achieved by separating them into a portable definition (in System) and an unportable implementation (in Host). The question arises if this separation is a general rule, which is sometimes violated, or if there are other aspects to be considered in order to understand and justify the current "System" structure.

This memo tries to shed some light on this question.

Let us first look at the exceptions. The most prominent exception is the module Kernel. There is no module HostKernel that provides the non-portable implementation of it. Similarly, the modules Math and SMath are exceptions because they use code procedures specific to the i387 coprocessor. On the other side, modules such as Files, Fonts, Ports, Dialog, etc. are split, i.e. there exists a corresponding HostFiles, HostFonts, HostPorts, and HostDialog module.

So what is the general rule behind this rather arbitrary looking situation. In order to answer this question, let us look into the module Fonts, for example. This module has an import of HostRegistry. HostRegistry in turn has an import of Dialog, among other imports. Now let us look into Dialog. We notice that it does not have any interesting imports, only some low-level modules that can be imported without any problems. Now let us assume that HostDialog and Dialog are not split. How would the situation be if we look at the union of both import lists? By looking into HostDialog we find a large number of imports including an import of Fonts. This is what is called a circular import, because Fonts is exactly the module we started with. We notice that the split of modules into a definition and an implementation is a means for avoiding a circular import. And this is actually the key for the understanding of the current "System" structure.

The rule is like this: Any module whose implementation may cause a circular import is split.

The module Kernel is considered to be the lowest-level module not importing any other module. Therefore it may not cause a circular import and it is not required to be split. In addition, splitting the module Kernel may cause problems when starting the system because Kernel contains the runtime system procedures that must be resolved by the loader. This may be more complicate if Kernel is split. Similarly, the modules Math and SMath are considered not to cause any circular imports because of their narrow focus. In addition, any indirection caused by a split would also slow down the execution.