2.2.2 The "native" model

This is Moscow ML's native model. The source code for the unit foo consists of the two files `foo.sml' and `foo.sig'. The `.sig' file describes the unit's exported interface and is compiled separately to `foo.ui'. Later, the `.sml' file is compiled to produce bytecode in `foo.uo' while checking that what the `.sml' actually exports match what the `.sig' file claims.

If the unit definition in the `Dependencies' file contains a `+' that is not part of a unit name (i.e., it must be surrounded by whitespace), the units to the left of the `+' will only be used for compiling the `.sml' file but not the `.sig' file. The units to the right of the `+' will be used for both compilations. Example. A line

foo: baz bar + quux

in `Dependencies' will lead to rules like these in `mosmake.dep':

foo.ui: baz.ui bar.ui foo.sig
        mosmlc -c -toplevel baz.ui bar.ui foo.sig
foo.uo: baz.ui bar.ui quux.ui foo.ui foo.sml
        mosmlc -c -toplevel baz.ui bar.ui quux.ui foo.sml

(execpt that the rules really produced are more complex to take account of various bells and whistles like the smartmake feature).

If there is no `+' in the `Dependencies' line, all the units mentioned will be used to compile the `.sig' as well as the `.sml' file.

For units compiled in "structure mode" (see section 2.3 Structure mode) this model is ideal, but there is a problem with "toplevel mode" (which is the default for Mosmake). Namely, if the `.sml' file defines a name that is not mentioned in the `.sig' file, you will get compiler warnings when compiling the `.sml' file. One way to avoid this is to wrap internal definitions in local ... in ... end blocks, but that can become unwieldy if the relationship between internals and exported functions is complex.

A better way to get rid of the warning would be to use an opaque signature constraint (:>), but here the problem is that the signature specified in the `.sig' is not in scope during the compilation of the `.sml' file. See section 2.2.3 The "full" model, for the recommended way to solve that problem.

Use the "native" model

• For units originally written for Moscow ML without thought of Mosmake.

• For units whose implementation contain few enough internal definitions that you find it manageable to protect them with local blocks.