2.2.1 The "simple" model

This is the most primitive model: The source code for the unit foo consists of a single file called `foo.sml'. A single mosmlc command translates it into `foo.uo' with compiled bytecode and `foo.ui' with inferred types (or signatures) for the values and functions (or structures) defined by `foo.sml'.

The main problem with this model is that the type information in `foo.ui' is inferred rather than speficied directly. If, for example `foo.sml' defines some functions that you think of as int list -> int list, perhaps the inferred type for one of them will be 'a list -> 'a list instead. Then bugs in dependent units that lead them to use your function with a bool list instead will be hard to find. More seriously, a bug in `foo.sml' may lead to one of the functions actually being int list -> int list list. You won't get any warning about this bug until you see strange type errors in the units that use the function.

Because of this, the "simple" model is not recommended for general use. There's a few situations where it comes in handy, though:

• If you're in a hurry and decide to worry about maintainability later.

• For the main unit of a stand-alone program. Such a unit does not export anything to other units, so its `.ui' file is never read at all.

• For a unit whose main task is to export type and/or signature definitions. Here, the `.sml' file's job is to explicitly specify what goes in the `.ui' file; the `.uo' file is just an inconsequential byproduct.

• For a unit that defines a structure with an opaque signature constraint, such that you still have explicit control over what's exported. However, there is still a problem in that the `.ui' file must be remade each time the implementation is changed, which could lead to a lot of recompilations of dependent units unless you're sure that you will never do any serious development on machines where Mosmake's smartmake feature (see section 2.2.6 The "smartmake" feature) doesn't work.