When you want to create your own modules, you have to take the following steps:
define-moduleform at the beginning.
export(both documented below).
module-name is of the form
(hierarchy file). One example of this is(define-module (ice-9 popen))
define-modulemakes this module available to Guile programs under the given module-name.
The options are keyword/value pairs which specify more about the defined module. The recognized options and their meaning is shown in the following table.
- Equivalent to a
)(see Using Guile Modules).
- Use module when loading the currently defined module, and install it as the syntax transformer.
- Load module when any of symbol-list are accessed. For example,(define-module (my mod) #:autoload (srfi srfi-1) (partition delete-duplicates)) ... (if something (set! foo (delete-duplicates ...)))
When a module is autoloaded, all its bindings become available. symbol-list is just those that will first trigger the load.
An autoload is a good way to put off loading a big module until it's really needed, for instance for faster startup or if it will only be needed in certain circumstances.
@can do a similar thing (see Using Guile Modules), but in that case an
@form must be written every time a binding from the module is used.
- Export all identifiers in list which must be a list of symbols. This is equivalent to
)in the module body.
- Re-export all identifiers in list which must be a list of symbols. The symbols in list must be imported by the current module from other modules. This is equivalent to
- Export all identifiers in list which must be a list of symbols. The identifiers in list must refer to macros (see Macros) defined in the current module. This is equivalent to
)in the module body.
- Re-export all identifiers in list which must be a list of symbols. The symbols in list must refer to macros imported by the current module from other modules. This is equivalent to
)in the module body.
- Export all identifiers in list (a list of symbols) and mark them as replacing bindings. In the module user's name space, this will have the effect of replacing any binding with the same name that is not also “replacing”. Normally a replacement results in an “override” warning message,
This is useful for modules that export bindings that have the same name as core bindings.
#:replace, in a sense, lets Guile know that the module purposefully replaces a core binding. It is important to note, however, that this binding replacement is confined to the name space of the module user. In other words, the value of the core binding in question remains unchanged for other modules.
For instance, SRFI-39 exports a binding named
current-input-port(see SRFI-39) that is a function which is upwardly compatible with the core
current-input-portfunction. Therefore, SRFI-39 exports its version with
SRFI-19, on the other hand, exports its own version of
current-time(see SRFI-19 Time) which is not compatible with the core
current-timefunction (see Time). Therefore, SRFI-19 does not use
#:replaceoption can also be used by a module which is intentionally producing a new special kind of environment and should override any core or other bindings already in scope. For example perhaps a logic processing environment where
<=is an inference instead of a comparison.
#:duplicates(see below) provides fine-grain control about duplicate binding handling on the module-user side.
- Tell Guile to handle duplicate bindings for the bindings imported by the current module according to the policy defined by list, a list of symbols. list must contain symbols representing a duplicate binding handling policy chosen among the following:
- Raises an error when a binding is imported from more than one place.
- Issue a warning when a binding is imported from more than one place and leave the responsibility of actually handling the duplication to the next duplicate binding handler.
- When a new binding is imported that has the same name as a previously imported binding, then do the following:
- If the old binding was said to be replacing (via the
#:replaceoption above) and the new binding is not replacing, the keep the old binding.
- If the old binding was not said to be replacing and the new binding is replacing, then replace the old binding with the new one.
- If neither the old nor the new binding is replacing, then keep the old one.
- Issue a warning when a core binding is being overwritten and actually override the core binding with the new one.
- In case of duplicate bindings, the firstly imported binding is always the one which is kept.
- In case of duplicate bindings, the lastly imported binding is always the one which is kept.
- In case of duplicate bindings, leave the responsibility to the next duplicate handler.
If list contains more than one symbol, then the duplicate binding handlers which appear first will be used first when resolving a duplicate binding situation. As mentioned above, some resolution policies may explicitly leave the responsibility of handling the duplication to the next handler in list.(replace warn-override-core warn last)
- Tell Guile not to record information for procedure backtraces when executing the procedures in this module.
- Create a pure module, that is a module which does not contain any of the standard procedure bindings except for the syntax forms. This is useful if you want to create safe modules, that is modules which do not know anything about dangerous procedures.
Add all variables (which must be symbols) to the list of exported bindings of the current module.