chickadee » chicken » modules » module

(module NAME (EXPORT ...) BODY ...)syntax
(module NAME (EXPORT ...) FILENAME)syntax
(module NAME * BODY ...)syntax
(module NAME = (FUNCTORNAME MODULENAME1 ...))syntax
(module NAME = FUNCTORNAME BODY ...)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.

NAME and FUNCTORNAME should be symbols or lists of symbols and integers, where (foo bar baz) is equivalent to

(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 as value bindings 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).

(module NAME = FUNCTORNAME BODY ...) is a special form of functor instantiation where the BODY implements a module satisfying a single functor argument to FUNCTORNAME.

Nested modules, modules not at toplevel (i.e. local modules) or mutually recursive modules are not supported.

When compiled, the module information, including exported syntax is stored in the generated binary and available when loading it into interpreted or compiled code. Note that this is different to normal syntax (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.