HCoop / hcoop / debian / mlton.git / blame
| Commit | Line | Data |
|---|---|---|
| 7f918cf1 CE |
1 | MLBasisSyntaxAndSemantics |
| 2 | ========================= | |
| 3 | ||
| 4 | An <:MLBasis:ML Basis> (MLB) file should have the `.mlb` suffix and | |
| 5 | should contain a basis declaration. | |
| 6 | ||
| 7 | == Syntax == | |
| 8 | ||
| 9 | A basis declaration (_basdec_) must be one of the following forms. | |
| 10 | ||
| 11 | * +basis+ _basid_ +=+ _basexp_ (+and+ _basid_ +=+ _basexp_)^*^ | |
| 12 | * +open+ _basid~1~_ ... _basid~n~_ | |
| 13 | * +local+ _basdec_ +in+ _basdec_ +end+ | |
| 14 | * _basdec_ [+;+] _basdec_ | |
| 15 | * +structure+ _strid_ [+=+ _strid_] (+and+ _strid_[+=+ _strid_])^*^ | |
| 16 | * +signature+ _sigid_ [+=+ _sigid_] (+and+ _sigid_ [+=+ _sigid_])^*^ | |
| 17 | * +functor+ _funid_ [+=+ _funid_] (+and+ _funid_ [+=+ _funid_])^*^ | |
| 18 | * __path__++.sml++, __path__++.sig++, or __path__++.fun++ | |
| 19 | * __path__++.mlb++ | |
| 20 | * +ann+ ++"++_ann_++"++ +in+ _basdec_ +end+ | |
| 21 | ||
| 22 | A basis expression (_basexp_) must be of one the following forms. | |
| 23 | ||
| 24 | * +bas+ _basdec_ +end+ | |
| 25 | * _basid_ | |
| 26 | * +let+ _basdec_ +in+ _basexp_ +end+ | |
| 27 | ||
| 28 | Nested SML-style comments (enclosed with `(*` and `*)`) are ignored | |
| 29 | (but <:LineDirective:>s are recognized). | |
| 30 | ||
| 31 | Paths can be relative or absolute. Relative paths are relative to the | |
| 32 | directory containing the MLB file. Paths may include path variables | |
| 33 | and are expanded according to a <:MLBasisPathMap:path map>. Unquoted | |
| 34 | paths may include alpha-numeric characters and the symbols "`-`" and | |
| 35 | "`_`", along with the arc separator "`/`" and extension separator | |
| 36 | "`.`". More complicated paths, including paths with spaces, may be | |
| 37 | included by quoting the path with `"`. A quoted path is lexed as an | |
| 38 | SML string constant. | |
| 39 | ||
| 40 | <:MLBasisAnnotations:Annotations> allow a library author to | |
| 41 | control options that affect the elaboration of SML source files. | |
| 42 | ||
| 43 | == Semantics == | |
| 44 | ||
| 45 | There is a <!Attachment(MLBasis,mlb-formal.pdf,formal semantics)> for | |
| 46 | ML Basis files in the style of the | |
| 47 | <:DefinitionOfStandardML:Definition>. Here, we give an informal | |
| 48 | explanation. | |
| 49 | ||
| 50 | An SML structure is a collection of types, values, and other | |
| 51 | structures. Similarly, a basis is a collection, but of more kinds of | |
| 52 | objects: types, values, structures, fixities, signatures, functors, | |
| 53 | and other bases. | |
| 54 | ||
| 55 | A basis declaration denotes a basis. A structure, signature, or | |
| 56 | functor declaration denotes a basis containing the corresponding | |
| 57 | module. Sequencing of basis declarations merges bases, with later | |
| 58 | definitions taking precedence over earlier ones, just like sequencing | |
| 59 | of SML declarations. Local declarations provide name hiding, just | |
| 60 | like SML local declarations. A reference to an SML source file causes | |
| 61 | the file to be elaborated in the basis extant at the point of | |
| 62 | reference. A reference to an MLB file causes the basis denoted by | |
| 63 | that MLB file to be imported -- the basis at the point of reference | |
| 64 | does _not_ affect the imported basis. | |
| 65 | ||
| 66 | Basis expressions and basis identifiers allow binding a basis to a | |
| 67 | name. | |
| 68 | ||
| 69 | An MLB file is elaborated starting in an empty basis. Each MLB file | |
| 70 | is elaborated and evaluated only once, with the result being cached. | |
| 71 | Subsequent references use the cached value. Thus, any observable | |
| 72 | effects due to evaluation are not duplicated if the MLB file is | |
| 73 | referred to multiple times. |