While some of modules may be complete and self-contained (and thus safely land on Mars surface), more of them are not, because need to refer to types and/or values defined somewhere else. Typically, if you are using libraries (no matter if self-made or not), you would expect some inter-module referencing possibilities.
First of all, you have to know, which definitions you want to use outside the module. Just enumerate them in an EXPORTS statement:
HumanBody DEFINITIONS ::=
BEGIN
...
LegsLenght ::= INTEGER (0..120)
...
EXPORTS LegsLenght;
END
A few comments to that. If you want to export all the definitions, do not include EXPORTS statement. You do not need as many EXPORTS statements as many definitions you want to export - just use one statement and separate references by commas - that's why EXPORTS statement must be terminated by semicolon. If no definitions are to be exported, simply type EXPORTS ; in the module.
OK, definitiions are exported, so how to import them where appropriate? As supposed, there is an IMPORTS statement as a oposite to EXPORTS. To distinguish between the same names in different modules, a FROM phrase is included, where appropriate module is refered. Here is an example:
IMPORTS LegsLenght FROM HumanBody;
It seems it needs some comments too. You can import more than one definition from the same module by enumerating them and separating by commas, then FROM phrase comes. It is also possible to import definitions from more than one module by enumerating them and terminate IMPORTS statement by semicolon.
Afer including this IMPORT statement into module code, you can freely use imported definitions such as they are definid locally. But may be in some occasions you will need to refer to a definition explicitly (two references of the same name from different modules). Then use so-called external reference, which consist of module name and definition reference separated by a period (no spaces), e.g.:
HumanBody.LegsLenght
This external reference allows you to access also unimported definition(s), but it is recommended not to use it unless two or more definitions are given the same name.
Remember: EXPORTS and IMPORTS statements must be included in this order at the very beginning of the module, before any internal definition.
Now go to the next page, if you want your ASN.1 code to be well readable. ASN.1 modules layout.