13.7 The time-library file
The |
|---|
Module: dylan-user // Library definition define library time // Interface module export time; // Substrate libraries use format-out; use dylan; end library time; |
| // Interface module define module time // Classes create <time>, <time-of-day>, <time-offset>; // Generics create say, encode-total-seconds; end module time; |
| // Internal substrate module define module sixty-unit // External interface use time; // Internal interface export <sixty-unit>, total-seconds, decode-total-seconds; // Substrate module use dylan; end module sixty-unit; |
// Implementation module define module time-implementation // External interface use time; // Substrate modules use sixty-unit; use format-out; use dylan; end module time-implementation; |
Because every file has to name the module to which its source records belong, you might wonder where to start. Every library implicitly defines a dylan-user module for this purpose. The dylan-user module imports all of the dylan module, so any Dylan definition can be used. You can think of dylan-user as being a scratch version of dylan. Each library has a private copy of dylan-user, so there is no concern that definitions in one library's dylan-user could be confused with those of another.
The purposes of the library file are to communicate to the Dylan compiler the structure of the module namespaces, to state which other libraries to search for the modules that are used in the implementation of this library, and to determine which modules implemented by this library are visible to other libraries (and programs) that use this library. The details of how these tasks are done depend on the implementation, but each environment will provide a mechanism for reading library and module definitions, either directly from an interchange file, or after conversion of the interchange file to an implementation-dependent format.