2.2.4 The "hybrid" model

This model has a `foo-sig.sml' file but no `foo.sig' file. Thus, it combines the advangages of the "full" model with the disadvantages of the "simple" model.

First, `foo-sig.sml' is compiled in the enviroment in which `foo.sig' file would have been compiled if it existed; see plus sign. Then `foo.sml' is compiled in an environment comprising all the units on its `Dependencies' line (ignoring a `+' separator if it exists) plus the definitions in `foo-sig.sml'.

Use the "hybrid" model

• As a quick(er) way to integrate sources that follow the SML/NJ convention of defining a named signature in a file called `foo.sig' and using it in a signature constraing in `foo.sml'. You will need to rename `foo.sig' to `foo-sig.sml', because mosmlc assumes that all `.sig' files belong to the "native" model whose `.sig' syntax won't accept the SML/NJ paradigm.

  You also still need to write down the dependencies between the units you import by hand. If anyone writes a tool that automatically creates a `Dependencies' file for Mosmake using dependency information from SML/NJ's Compilation Manager, I'd love to hear about it.

• As an alternative to the "full" model if you're sure that you'll never need to do serious development work on a system where the smartmake feature (see section 2.2.6 The "smartmake" feature) doesn't work. Then you don't need to clutter your directories with `.sig' files, and Smartmake makes sure that you can change the implementation of a unit witout necessarily recompiling the units that depend on it.