Overview of modules
module() export eseq; local lseq; global gseq; option optseq; description dseq; uses usesSequence; statementSequence end module
expression sequence of exports
expression sequence of locals
expression sequence of globals
expression sequence of options
sequence of description strings
names of packages or other modules the module uses
sequence of statements
A module is a first-class Maple expression that is created as a result of evaluating a "module definition." A module definition is constructed by the Maple parser when it reads the syntax summarized above.
The syntax for module definitions is similar to the syntax for procedure definitions. A module definition begins with the Maple keyword module, followed by a pair of parentheses, followed by zero or more statements (described below), and closed by the keyword end or the combination end module. Thus, the shortest possible module definition is module() end.
As with a procedure, a module definition can include several optional "declarative" clauses. The local, global, option, description, and uses clauses are exactly the same as for procedure definitions. (The valid or useful specific options differ, however.)
A module can be thought of as a collection of name bindings. Some of these bindings are accessible to Maple code outside the module, after the module has been constructed; these are the "exports" of the module. For more information, see module[export].
Other local name bindings in a module are accessible only during the instantiation of the module, that is, within the body of the module definition. These are its local variables, declared either explicitly in the local declaration of the module (recommended), or implicitly through Maple implicit scoping rules. For more information, see module[local].
All other names that occur in a module definition are bound either globally, or to a parameter or a local name bound in an enclosing scope. Variables that appear in a module may be bound globally by being explicitly declared global in the global declaration of the module, or through Maple implicit scoping rules applied during simplification.
The uses statement is equivalent to wrapping the statementSequence with a use statement. In other words,
module ... uses LinearAlgebra; ... end module
is equivalent to:
module ... use LinearAlgebra in ... end use; end module
Every module has a statementSequence that consists of zero or more ordinary Maple statements. These statements are used to define initial values for the exported members of the module, and to perform arbitrary computations during the module instantiation.
The collection of names that appear in the body of a module definition, and their bindings, constitute a complete lexical scope. This is exactly analogous to the body of a procedure definition, using the same lexical scoping rules and implicit scoping rules.
Module and procedure definitions may be arbitrarily and mutually nested. The static scoping rules of Maple ensure that the bindings of names implied by any such nesting are lexically apparent.
Module members, whether local or exported, may be assigned any Maple expression; this includes modules. A module that is a member of another module is called a submodule of the module.
A module is created by evaluating a module definition. A module definition is evaluated as much as a procedure definition is evaluated. However, after a process that mimics procedure evaluation, an invocation step follows that is analogous to calling or invoking a procedure. In principle, a module evaluation works like the following example that uses only procedures.
makezp := proc(N::posint)
local plus, times; # will be "exported"
plus := (a,b) -> a + b mod N;
times := (a,b) -> a * b mod N;
plus, times # return "exports"
z5 := makezp(5); # a simplified "module"
Written as a module, this becomes
z5 := module()
export plus, times;
plus := (a,b) -> a + b mod 5;
times := (a,b) -> a * b mod 5;
You can think of a module as the result of invoking a procedure that "returns" some of its local variables (its exported locals).
Modules can, like every Maple expression, be saved in a "repository," which is a kind of library structure for storing persistent Maple objects between sessions. Maple repositories are explained in repository and repository/management. To save a module in a repository, set the global variable savelibname to the repository in which it is to be saved (that is, the name of the directory containing the repository files), and call the savelib command with the name of the module as argument. For more information, see savelib, repository, and repository/management.
Modules have three operands, which are accessible using op.
* op 1 is the eseq of exports
* op 2 is a pointer to a module definition "shell"
* op 3 is the lseq of locals
Moddefs have eight operands, which are accessible using op.
* op 1 is the sequence of (implicit) parameters
* op 2 is the expression sequence of local variables
* op 3 is the expression sequence of options
* op 4 is the expression sequence of exports
* op 5 is the expression sequence of description strings
* op 6 is the expression sequence of globals
* op 7 is the sequence of lexicals
* op 8 is the name of a named module
Note that the module definition shell to which the module points is not the original module definition, but rather a stripped-down copy of it without any code. It is used only for pretty-printing the module.
If a module has an export named ModuleApply, that procedure is invoked when the module is called as if it were a function. The call M(args) invokes M:-ModuleApply(args).
If a ModuleLoad local or export is present, then this procedure is called when the module is read from the Maple repository in which it is found.
If a ModuleUnload local or export is present, then this procedure is called when the module is destroyed (when it is no longer accessible and is garbage collected, or when Maple exits).
If a module has an export or local named ModulePrint, the result of the ModulePrint() command is displayed instead of the module when a command in that module is executed.
When debugging code that uses modules, set kernelopts(opaquemodules=false) to make local members of the module accessible outside of the module. For more information, see kernelopts.
Download Help Document
What kind of issue would you like to report? (Optional)