A clarification about module parameters
Last updated at 2:34 pm UTC on 16 January 2006
(Les Tyrell asked about the need to declare all external modules by their explicit names.)
Module parameters
Consider the analogy between my module format and methods, i.e., module parameters/imports are like method arguments. In particular this means that you should be able to specify the parameters from the outside (but with an option to provide defaults), when you "instantiate" a module.
Example: ModuleX accesses the Transcript, but wants to allow multiple implementations of the Transcript. This is acheived by letting ModuleX take a parameter TranscriptModule that you provide when ModuleX is included in your system. So, when SystemY has ModuleX as part of it, the build schema for SystemY says something like
SystemY submodule: (ModuleX transcriptor: GuiTranscriptModule)
whereas a headless system might say:
MyServer submodule: (ModuleX transcriptor: StdoutTranscriptModule)
modulo the specific details.
So, the main point to undersatnd is that imports are effectively parameters: they should always be specifiable from the outside; this adds some extras to the specification. Submodules, in contrast, are part of the module, i.e., they are specified inside the module.
