chickadee » chicken » modules » module

(module NAME (EXPORT ...) BODY ...)syntax
(module NAME (EXPORT ...) FILENAME)syntax
(module NAME * BODY ...)syntax
(module NAME1 = NAME2 [BODY ...])syntax
(module NAME = (FUNCTORNAME MODULENAME1 ...))syntax

Defines a module with the name NAME, a set of exported bindings and a contained sequence of toplevel expressions that are evaluated in an empty syntactical environment.

(EXPORT ...) should be an export-specification which holds a list of identifiers to be exported from the module and which should be visible when imported into another module or the toplevel environment. EXPORT may have any of the following forms:

IDENTIFIER names a value- or syntax binding to be exported.

(IDENTIFIER1 ...) or (syntax: IDENTIFIER1 ...) exports IDENTIFIER1 (which should name a macro) and also arranges for the remaining identifiers in the list to be visible in the expansion of the macro (this is a hint to the module expander to export bindings referenced by syntax-definitions which make use of them, but which would normally be internal to the module - which gives more opportunities for optimization).

(interface: INTERFACENAME) adds all exports defined for the given interface to be added to the list of exported identifiers of this module.

As a special case, specifying * instead of an export-list will export all definitions. As another special case, the export-list may be a symbol naming an interface.

When the BODY consists of a single string, it is treated like (include FILENAME).

(module NAME = (FUNCTORNAME MODULENAME1 ...)) instantiates a functor (see below for information about functors).

The syntax (module NAME1 = NAME2) defines an alias NAME1 for the module NAME2, so NAME1 can be used in place of NAME2 in all forms that accept module names. Module aliases defined inside a module are local to that module. If followed by a module body, then this is a special form of functor instantiation.

Nested modules, modules not at toplevel (i.e. local modules) or mutually recursive modules are not supported. As an exception module alias definitions are allowed inside a module definition.

When compiled, the module information, including exported macros is stored in the generated binary and available when loading it into interpreted or compiled code. Note that this is different to normal macros (outside of module declarations), which are normally not exported from compiled code.

Note that the module system is only a device for controlling the mapping of identifiers to value or syntax bindings. Modules do not instantiate separate environments that contain their own bindings, as do many other module systems. Redefinition or assignment of value or syntax bindings will modify the original, imported definition.

Syntax expansions may result in module-definitions, but must be at toplevel.