links to this page:    
View this PageEdit this PageUploads to this PageHistory of this PageTop of the SwikiRecent ChangesSearch the SwikiHelp Guide
Module structure
Last updated at 12:16 pm UTC on 28 September 2001

Module Structure

A module

Think of the parameters as imports, ie. other (external) modules that this module needs to access.

From this, a module definition has the abstract form

Module (parameters/import list) -> submodule list.

Also, these imports and submodules could be seen as the arguments and temporary variables of a method, respectively.

The reason for this format choice is that by combining elements of this single format you can define any possible structure. (This is a graph-theoretical result.) In contrast, for example single-path inheritance places a narrow restriction on how you can structure different modules wrt each other; you would soon encounter cases which couldn't be handled by such a scheme. With this format that cannot happen.

A second reason is that this format provides a simple and familiar way of thinking about module structure: Each module is composed out of submodules, together forming a tree of nested modules. This also allows for UI tools to visualize module structures in a straightforward way, either as trees or indented lists. (Imports corresponds to crossreferences in a module hierarchy.)

Inside a module, both imports and submodules are accessible by their names. Thus from code inside the module the two kinds are indistinguishable. The difference between them is that submodules are considered to be subparts of the module (ie. the module's definition), whereas parameters are not considered part of it, but as external and just made available to it. (This matters in certain cases, e.g. if you would unload a project from the image, its submodules would also be unloaded as parts of it, whereas imports would not.)

Instead of a single path of inheritance for the names available in a Module, it should be possible to delegate name lookup to any (possibly several) imported module or submodule, by marking those modules for delegation. (The present scheme is equivalent to how Self replaces s.i. with its multiple inheritance/delegation scheme, where submodules correspond to slots and delegation corresponds to marking a self slot as a parent, except in that you can delegate also to imported modules.) Simple conflict resolution can be done by specifying an ordered lookup of submodules and imports (in the order of declaration).