The compiler directives

The compiler accepts four different types of directives: the uses statement, the imports statement, the options statement and the version statement. Namespace declarations are also expressed by means of directives, see Section Namespaces for further explanations.

Directive uses

The general form of a uses statement is:

This clause asks the compiler to load the listed modules or packages and import the symbols they define. Both modules and packages must still be available for running the model. If the source file being processed is a package, the bim files associated to the listed packages must be available for compiling another file using this package. It is also possible to merge bim files of several packages by using imports instead of uses when building packages.

By default the compiler tries first to find a package (the corresponding file is libname.bim) then, if this fails, it searches for a module (which file name is libname.dso). It is possible to indicate the type of library to look for by appending either ".bim" or ".dso" to the name (then the compiler does not try the alternative in case of failure). A package may also be specified by an extended file name (see Section File names and input/output drivers) including the IO driver in order to disable the automatic search (i.e. "a.bim" searches the file a.bim in the library path but ":a.bim" takes the file a.bim from the current directory).

For example,

uses 'mmsystem','mmxprs.dso','mypkg.bim'
uses ':/tmp/otherpkg.bim'

Both packages and modules are searched in a list of possible locations. Upon startup, Mosel uses as the default for this list the value of the environment variable MOSEL_DSO completed by a path deduced from the location (rtdir) of the Mosel runtime library (in the following # can be "32" on a 32bit system, "64" on a 64bit system or an empty string):

"rtdir\..\dso#"

Under Windows if rtdir terminates by "\bin#" and "rtdir\..\dso#" exists or

"rtdir/../dso#"

On Posix systems if rtdir terminates by "/lib#" and "rtdir/../dso#" exists or

"rtdir/dso#"

if this directory exists or

"rtdir"

if none of the above rules apply

The variable MOSEL_DSO is expected to be a list of paths conforming to the operating system conventions: for a Posix system the path separator is ':' (e.g. "/opt/Mosel/dso:/tmp") and it is ';' under Win32 (e.g. "E:\Mosel\Dso;C:\Temp"). The search path for modules and packages may also be set from the mosel command (using the -dp option, see Section Running Mosel) as well as inspected and modified from the Mosel Libraries (see functions XPRMgetdsopath and XPRMsetdsopath in the Mosel Libraries Reference Manual). Note however that Mosel will ignore modules not located in read-only locations when the restriction NoExec is active (see Section mosel command: restricted mode).

For locating packages Mosel will use the list of prefixes defined by the compiler option -bx (Section Running Mosel) or the environment variable MOSEL_BIM before proceeding to the search as decribed above. This parameter consists in a list of strings separated by the sequence || that are used as prefixes to the package name. For instance if the option -bx "bimdir/||tmp:" is used with the directive uses 'mypkg', the compiler will try to load the package "bimdir/mypkg.bim", then "tmp:mypkg.bim" before looking for "mypkg.bim" and "mypkg.dso" in the usual locations.

Directive imports

The general form of an imports statement is:

This clause is a special version of the uses directive that can only be used for packages: it asks the compiler to load the listed packages, import the symbols they define and incorporate the corresponding bim file. As a consequence, the generated file provides the functionality of the packages it imports. When used on a model file it removes the dynamic dependency on the listed packages (i.e. these packages are no longer required to run the model).

For example,

imports 'mypkg' 

Directive options

The compiler options may be used to modify the default behaviour of the compiler. The general form of an options statement is:

The supported options are:

• explterm: asks the compiler to expect explicit expression termination (see Section Separation of instructions, line breaking).
• noimplicit: disables the implicit declarations (see Section About implicit declarations). This option can also be activated by using the '-ni' compiler flag (see Section Running Mosel)
• noautofinal: by default initialization from blocks finalize sets they populate (section About automatic finalization). This option disables this behaviour that may be activated afterwards using the autofinal control parameter (cf. setparam).
• keepassert: assertions (cf. assert) are compiled only in debug mode. With this option assertions are preserved regardless of the compilation mode.
• xbim: store additional symbol information in the generated bim file (in particular array index names). This option can also be enabled by using the '-I' compiler flag (see Section Running Mosel).
• fctasproc: by default return values of functions must be used such that a function call is not a valid statement. With this option functions can be used as procedures: when a statement consists in a function call its return value is silently ignored (see also asproc).
• tagpriv: when the model is compiled with debug information private symbols are preserved. When this option is used these symbols are prefixed with '∼' such that they can be easily identified.
• dynonly: this option can only be applied to a package: it marks the package as dynamic only such that it cannot be imported (see Section Directive imports).

For example,

options noimplicit,explterm 

Directive version

In addition to the model/package name, a file version number may be specified using this directive: a version number consists in 1, 2 or 3 integers between 0 and 999 separated by the character '.'.

For example,

version 1.2 

The file version is stored in the BIM file and can be displayed from the Mosel console (command list) or retrieved using the Mosel Libraries (see function XPRMgetmodprop in the Mosel Libraries Reference Manual). From the model itself, the version number is recorded as a string in the control parameter model_version (see function getparam).