Modules

Modules are used for creating large-scale namespaces of bindings. The bindings accessible in a module are visible to all the code within the module (except where shadowed by a local binding). Only the bindings explicitly exported are visible from outside the module.

Some languages have module systems with distinct support for exporting variables, functions, types, and classes. Dylan modules operate only on bindings. Because functions and classes are commonly named by bindings, access to them is controlled by controlling access to the bindings that name them. By exporting the binding naming a class or function, a program has effectively exported the class or function. If the binding is not exported, then the class or function is effectively private.^*

A module definition defines the imports and exports of a module, and may specify bindings owned by the module. A complete description of module definitions is given on page 381.

Defining Module Bindings

A module consists of a set of bindings. A binding may be owned by a module, or a module may import the binding from another module by using the other module. Modules export bindings to make them accessible to other modules. Only exported bindings can be imported by other modules.

Module-use relationships may not be circular. To create a common set of bindings for a group of modules, the modules can import the bindings from another module or modules.

Within a given module, a name refers to at most one module binding. It is an error to create or import two or more different bindings with the same name in a single module. If a name does refer to a binding, the binding is said to be accessible from the module. Each binding is owned by exactly one module, but it can be accessible from many modules.

Module bindings are created by definitions. Explicit definitions are created by define constant, define variable, define generic, define macro and the class name in define class. Implicit definitions are created by define method and the slot specifications of define class.

Within a library, a module binding may have no explicit definition or it may have one explicit definition. It may not have more than one explicit definition. If a module binding has no explicit definition, it must have one or more implicit definitions. If it does have an explicit definition, it can have zero or more implicit definitions.

A binding may be declared by the create clause of a module definition. This does not define the binding, but instead declares that it is owned by the module. Other modules may import the binding from that module. The binding must be defined by one of the modules that imports it.

If a binding is not declared by the create clause of a module definition, it is owned by the module in which its explicit definition appears. If it does not have an explicit definition, it is owned by one of the modules in which at least one of its implicit definitions appears; the exact owning module cannot be determined.

It is an error to reference a name for the purpose of getting or setting its value if the name does not designate either a local or module binding in the environment where the reference occurs.

^* This privacy can sometimes be circumvented through certain introspective operations.