Compilation units and Moscow ML

The distinction between modular programming and core language programming in Standard ML is principally an issue of size. It is expected that modular programs will be larger than core language programs. For this reason Moscow ML separates out the use of structures into a compile and load phase. Furthermore it imposes a convention that signatures and structures must be stored in separate files--not within the same file and not keyed in at the top-level interactive loop--and lastly mandates that the signature, structure and file name are all the same, with a .sig suffix for the signature and a .sml suffix for the structure. Putting all of the pieces together we have a setup as shown in Figure 9.1.

Figure 9.1: File names in Moscow ML

We place the signature and the structure in separate files as shown. Please note that these files are not terminated by semicolons. Below we show how these files would be first compiled and then loaded into a Moscow ML session. User interaction is in italic type, system responses in upright type.

Notice that the functions compile and load are invoked here instead of the use function which performed both of these tasks for core language files. When compared to the chatty use function, the compile function seems rather sullen and untalkative. You can restore Standard ML's normal sunny disposition by the assignment verbose := true. Now the signature will be printed upon compilation of the .sig file and the principal signature will be printed upon compilation of the .sml file. Loading remains petulant.

The compilation of the Set.sig file produces a Set.ui file--the user interface--and the compilation of the Set.sml file produces a Set.uo file--the user's object code. It is these files which are loaded by the load function. Providing separate compilation and loading has an advantage in that we need only compile a signature or structure once to be able to load it in several different interactive sessions. When developing a large modular program we do not need to re-compile those modules which have not changed since the previous compilation. The flip side of this saving in compilation time is that we must actually remember to re-compile the files after we have changed them. If we do not then we will go on merrily using the object code from the previous compilation. Unix enthusiasts can use the `make' utility and the Moscow ML batch compiler mosmlc to help with this administrative detail.

Moscow ML will flag as erroneous a structure S without a signature constraint if a file with the name S.sig is present in the current working directory. Similarly, Moscow ML will flag as erroneous an attempt to compile a structure without first compiling a signature which it uses.