Prev: Memory Allocation

Module Loading and Initialization

When the m compiler processes a use clause, it first checks whether a module has already been loaded. If it has been loaded, the compiler simply continues. If it has not been loaded, the following happens:

1. The compiler searches for a DLL with name module_mm.dll
2. If there is no such DLL, it attempts to load the source of a module written in m.
3. If there is a DLL, it attempts to load it.
4. It then calls the DLL's first exported function, assuming the returned object being an implementation of the abstract class NativeModule.
5. It checks some magic tag and the runtime version expected by the module.
6. It assigns a reference to an implementation of class Runtime to the module's runtime member.
7. It calls the module's second phase constructor ConstructL().

Any error in each of the above phases causes compilation to be aborted (if the use clause specified a try, an error results in an empty module stub with version null).

Since errors during loading and initialization cannot be catched or handled by an m script, any module specific initialization like connecting to servers, opening files and such should be delayed until the first call of ExecuteL() whenever possible. This also avoids allocating resources if no functions of the module are ever going to be called.

---

Next: Restrictions

Navigation