[MLton] Combining signatures in SML'97

[Stephen Weeks]

> Working on the extended basis library I noticed that I have duplicated
> many specifications in various signatures. 
...
> Instead of duplicating specs and documentation, I'd like to be able
> to write signatures for concepts such as "ORDERED", "SIGNED", and
> "BOUNDED" once and for all and then create signatures by combining
> such concept (or mixin) signatures (using include).
...
> A common SML convention is to name the main (usually abstract) type of a
> signature "t".  Unfortunately, if two SML signatures have a specification
> in common, they can not both be included side-by-side.  Thus the "t"
> convention effectively prevents combining signatures in SML'97. 
...
> While the "t" convention is not appropriate for concept signatures,
> it could be used in other kind of signatures.

I agree with your assessment.  Although it makes sense to use non-"t"
type names in abstract (I prefer "abstract" to "concept") signatures,
one should always use type "t" in concrete signatures so that module
users don't have to remember any special names.

> So, instead of always using "t" or some artificial variation of "t" like
> "also_t", "t'", or "t0", concept signatures need a naming convention that
> ensures, as far as possible, that we can combine those signatures when it
> makes sense.

Good idea.

There are (at least) two important benefits of building up signatures
using include as you did.  One is the savings in writing the
specifications and documentation.  I would even hope that whatever
documentation tool we settle on could "follow the includes" to build
documentation for the whole signature.  Another important benefit of
using include is that it provides users of the library with a
subtyping hierarchy that allows them to remember less as well as to
more easily apply functors.

A convention to express the subtyping hierarchy is to use functors to
express subtypes.  For example, one could write

  functor F (S: INTEGER): ORDERED = S

This provides a static check of the subtyping, as well as a concise
description that can be read by a library user.  For an example of an
entire hierarchy see

  svn://mlton.org/mltonlib/trunk/com/sweeks/basic/unstable/subtypes.sml

It would be neat (and easy) to automatically extract a dot graph from
such code and give a nice picture of the hierarchy as part of library
documentation. 

One thing I'm not sure about is whether there should be a naming
convention to distinguish abstract signatures from concrete ones.  In
particular, we need both INT_CONCRETE (which has type t) and
INT_ABSTRACT (which doesn't).  My gut feeling is to use INT for the
concrete one since concrete signatures will be used more often, and
reserve part of the namespace (' suffix, _ABS, ...?) for abstract
signatures.

BTW, it should be SCANNABLE, not SCANABLE.