Introduction

The Mosel language is extensible by the means of modules. A module may define

• constants
• subroutines
• types
• operators for the types defined by the module
• I/O drivers
• control parameters

Constants that are used by several Mosel programs could be defined by a module; a module may also publish constants that are to be used in combination with its types or subroutines.

Subroutines are probably the most common use of modules. These may be entirely new functions or procedures, or overload existing subroutines of Mosel.

Defining new types requires a little more work, but as a result the user defined types will be no different from Mosel's own types (like integer or mpvar). So user defined types can be used in complex data structures (arrays, sets), read from file in initializations sections, appear as parameters of subroutines, or have operators applied to them.

The Mosel distribution comes with a set of I/O drivers that provide interfaces to specific data sources (such as ODBC) or serve to exchange information between the application running the Mosel libraries and a Mosel model in a very direct way by providing various possibilities of passing data back and forth in memory. The user may define additional drivers, for instance to read/write compressed or encrypted files. For examples of the use and definition of I/O drivers the reader is refered to the Xpress Whitepaper `Generalized file handling in Mosel'.

Control parameters make little sense on their own. They may be used for directing the behavior of subroutines defined by a module (e.g. algorithmic settings) or obtaining status information from a module. The values of control parameters may be changed from within a Mosel program.

Depending on the purpose of the module, it needs to provide one or several of the following to Mosel

• a list of constants
• a list of subroutines
• a list of types
• a list of services

Services are functions that Mosel calls at predefined places to perform tasks that may be characterized as `administration' of the module: the definition of types makes a reset functionality necessary; control parameters are retrieved and enumerated through service functions; other service functions may be activated during the checking of the version number and when Mosel unloads the module. I/O drivers are also defined as services. A module that only defines constants or subroutines may not require any specific services.

Mosel expects the required information to be formatted correctly. In the following pages we shall see a few examples how this is to be done. The first example, in Chapter Defining constants, shows how different types of constants are defined in a module. The following chapter lists and comments the complete code of a module that implements a single subroutine. Chapters Creating external types and Creating external types: second example give examples of the implementation of new types. In Chapter Creating external types this is a structure grouping data items of various types and in Chapter Creating external types: second example a new numerical type is defined. Chapter Control parameters adds the definition of parameters to the module from Chapter Creating external types.
A specific set of NI functions and data structures are dedicated to the generation and handling of the matrix representation for LP/MIP solvers, Chapter Implementing an LP/MIP solver interface documents an example implementation for basic solver access functionality for Xpress Optimizer.
If the Mosel program that uses a module is compiled and executed from a C program, then the definition of the module can be included directly in this C program. Chapter Defining a static module gives an example of such a static module.