All module definitions have an implicit parameter called thismodule. Within the body of a module definition, this special name evaluates to the module in which it occurs. You can, therefore, refer to a module within its own definition before the result of evaluating it has been assigned to a name.

thismodule is similar to thisproc in procedures, but is not the same as procname.  The difference between thismodule and procname is that procname evaluates to a name, while thismodule evaluates to the module expression itself. There is no concept of a modulename implicit variable because the invocation phase of evaluating a module definition is part of its normal evaluation process, and it occurs immediately. Procedures, on the other hand, are not invoked until they are called with arguments. Normally, at least one name for a procedure is known by the time it is called; this is not the case for modules.

Implicit parameters related to passing arguments (for example, _params, _options, _passed, and others) cannot be referenced in module definitions. They are only available within the scope of a procedure.

For more information on procedures, see Procedures.

You can provide a brief description to summarize the purpose and function of your modules. Providing a description is valuable to other users who read your code. Include text after the description keyword as you would in a procedure definition.

When the module is printed, its description string is displayed.

The export declaration is described later in this chapter.

Global variables referenced in a module definition are declared by using the global keyword. Following the global keyword is a sequence of one or more symbols, which are associated with their global module instances. In certain cases, you must declare a name as a global variable to prevent implicit scoping rules from making it local.

You can define variables that are local to the module definition by using the local declaration. Its format is the same as for procedures. The following example is a variant of the previous Hello module, which uses a local variable.

Local variables (or locals) cannot be used or changed outside of the module definition in which they occur. In other words, they   are private to the module.

A local variable in a module is a distinct object from a global variable with the same name. While local variables in procedures are typically used only for the duration of the execution time of the procedure body, module local variables are stored after the module definition is executed.  They can be used to maintain a state. For example, in the Counter example described at the beginning of this chapter, a local count variable stores the current value of the counter. The count local variable increments each time the getNext procedure is invoked. Its new value is stored and can be used the next time the procedure is called. At the same time, because count is local, no external programs can change its value and end the sequence defined by the module.

You can determine the names of the exports of a module by using the exports procedure.

This procedure returns the global instances of the export names.

You can also obtain the local instances of those names by using the option instance.

You cannot have the same name declared as both a local variable and an exported local variable.

(The declared exports and locals actually form a partition of the names that are local to a module.)

As described in previous chapters, the member command can be used to test whether a value is a member of a set or list.

This command can also be used for membership tests in modules.

The first argument is a global name whose membership is to be tested, and the second argument is the name of a module. The member command returns the value true if the module has an export whose name is the same as the first argument.

The member command also has a three-argument form that can be used with lists to determine the first position at which an item occurs.

The name pos is now assigned the value 2 because b occurs at the second position of the list. [ a, b, c].

When used with modules, the third argument is assigned the local instance of the name whose membership is being tested, provided that the return value is true.

If the return value from the member command is false, the name remains unassigned or maintains its previously assigned value.

A package is a collection of procedures and other data that can be treated as a whole. Packages typically gather several procedures that allow you to perform computations in a well-defined problem domain. Packages can contain data other than procedures and can even contain other packages (subpackages).

The package option is used to designate a module as a Maple package. The exports of a module created with the package option are automatically protected.

For more information, see Writing Packages.

The record option is used to identify records, which are fixed-size collections of items. Records are created by using the Record constructor and are represented using modules.

For more information, see Records.

When a procedure named ModuleApply is declared as an export or local of a module, the module name can be used as if it were a procedure name.

Consider the Counter example described at the beginning of this chapter. Since it only has one method, the calling sequence can be shortened by using the ModuleApply function.

In this example, calls to Counter:-ModuleApply() are not needed and the results are the same as those generated by the original Counter example. The ModuleApply function can specify and accept any number of parameters.

You can also use the ModuleApply function to create module factories, a standard object-oriented design pattern described later in this chapter.

The ModuleIterator procedure defines how a module functions when it is used as the in clause of a for loop.  

In the example below, the ModuleIterator procedure returns two procedures: hasNext and getNext. These procedures can have any names, and in fact, do not require names. When the ModuleIterator procedure is called, an iterator is initialized for the instance, the details of which are kept hidden from the caller. The two returned procedures can then be used to iterate over the instance to perform a specific task. For example, consider a class that implements a form of a set of which mySet is an instance. You can iterate over this set as follows (passing i is only necessary if the index is needed):

The example above is an explicit use of the ModuleIterator procedure. However, this mechanism is also used implicitly by the Maple for-loop construct,

The hasNext procedure returns a value of true or false depending on whether remaining elements need to be processed. Successive calls to hasNext with no intervening calls to getNext return the same result. The getNext procedure returns the next element to process, and increments the iterator. If an argument was passed to getNext, it will be an unevaluated name, and getNext should assign to it an index corresponding to the iterator (one that has meaning to some other procedure in the module that can be used to look up an entry using this index). If the concept of an index does not make sense for this particular module, getNext should not perform the assignment. These procedures should be implemented so that it is always safe to call getNext after the most recent call to hasNext returns a value of true. The result of calling getNext after hasNext has returned a value of false, or before hasNext has ever been called, is up to the implementer of the class.

The following example implements a fixed-size container of a collection of strings. In a real-world use case, these might have been other values that are expensive to compute, so we allocate this module to collect them for convenient access.

This loop will enumerate only the words in the CommonWords module:

This loop will enumerate both the words and their indices:

Notice that the ModuleIterator procedure declares a local variable, i, that is used as the index by hasNext and getNext. If this variable were declared local to the entire module, then it would only be possible to iterate over it once, as i would never get reset to 1. By declaring i local to ModuleIterator, it becomes part of the environment for the instances of hasNext and getNext returned by a particular call to ModuleIterator. Thus, multiple iterators into the same module can exist simultaneously without interfering with one another. For example:

When the module iterator is used by the seq, add, or mul commands, Maple first checks if the module is an object that exports the numelems command. If so, it will call the numelems command to determine how large to preallocate the result, and the hasNext and getNext procedures must return exactly that many elements. If the module does not export a numelems method, Maple will enlarge the result as needed, which will consume more space (as intermediate results are discarded) and time (garbage collection), although Maple will try to do this as efficiently as possible.

The ModuleLoad procedure is executed automatically when a module is loaded from the Maple library archive in which it has been saved. In a normal session,  initialization code can be included in the module body. When loading a saved module, extra initialization code is sometimes required to set up run-time properties for the module. For example, a module that loads procedures from a dynamic-link library (.dll) file may need to call the define_external function during the initialization process. For more information on the define_external function, see Advanced Connectivity.

Consider the Counter example at the beginning of the chapter. The count index can have any value when it is saved. The next time you use it, you might want to reset the count to zero so that it is ready to start a new sequence. This can be done by using the ModuleLoad procedure.

Note that the initialization code is contained within the ModuleLoad procedure. After that, the ModuleLoad procedure is also called. By defining the module in this way, you will get the same results when executing the module definition as you would when loading a saved module from a library archive.  

The results of ModuleLoad can be duplicated using a procedure with a different name by using the load=pname option in the option sequence of the module.

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.

The ModulePrint procedure does not display output. Instead, it returns a standard Maple expression that will be displayed. The expression returned can be customized to another object that portrays or summarizes the module.

In the following example, the Counter example will be extended from the ModuleIterator example to display a summary of what the module does.

The ModuleUnload procedure is called immediately before a module is discarded. A module is discarded either when it is no longer accessible and is garbage collected, or when you end your Maple session.

You may not see the "I am gone" message after executing the code above because several factors determine exactly when memory is free to be garbage collected. At a minimum, no references can be left in the module. It must not be assigned or contained in any other live expression. This includes the ditto operators and the list of display reference handles (that is, the undo/redo buffer of the GUI). Also, it must not be identified as being alive by the garbage collector (i.e. a reference to the module is not found by the collector).

A module can become inaccessible, and therefore subject to garbage collection before the unload= procedure is executed, but can then become accessible again when that procedure is executed. In that case, the module is not garbage collected. When it eventually is garbage collected, or if you end your Maple session, the unload= procedure is not executed again.

The behavior of ModuleUnload can be duplicated using a procedure with a different name by using the unload=pname option in the option sequence of the module.

The Counter example used up to this point would be more useful if you could have many Counter modules running at the same time, and if they could be specialized according to specified bounds. Modules do not take explicit parameters, but you can write a generic module that could be specialized by using the factory design pattern.

To do this, write a constructor procedure for the module that accepts the lower and upper bound values as arguments. The following module creates a Counter.

In the above example, two specialized Counters operate at the same time with different internal states.