A second set of rules determines how EGL resolves variable references. For details, see References to variables and constants.
In the simplest case, you define parts one after the next in a single package, without declaring one part within another. The following list omits many details, but shows a series of parts that are at the same hierarchical level:
Function: Function01 Function: Function02 Function: Function03 Record: Record01
Parts at the same level are available to one another. Function01, for example, can invoke one or both of the other functions; and Record01 can be used as a typedef for variables in each of the three functions.
Program: Program01 Function: Function01 Function: Function02 Function: Function03 Record: Record01
Finally, if your code includes text or print forms, a use declaration is necessary to access the form group that includes those forms. A use declaration is also desirable when accessing data tables or libraries. For additional information, see Use declaration.
Most development efforts have parts that are shared across more than one package. These rules are in effect:
my.package.myPart
As noted earlier, you can specify the name of a package when referencing a part, as in the example my.package.myPart. The current project is considered, as are any projects listed in the EGL build path.
Each import statement in this case explicitly references a particular part in a particular package. The part named in such an explicit-type import statement acts as an override of the same-named part in the current package.
If you have identically named packages in two different projects, a given explicit-type import statement uses the EGL build path to do a first-found search, stopping when the required part is found. (The part must be unique to a package in a given project.) The presence of a same-named package in two different projects is not an error, but creates a confusing situation and is not recommended.
An error occurs if you have two explicit-type import statements that name the same part.
Each import statement in this case references all parts in a given package and is called a wild-card import statement.
If you have identically named packages in two different projects, a given wild-card import statement uses the EGL build path to do a first-found search, stopping when the required part is found. (The part must be unique to a package in a given project.)
If more than one wild-card import statement retrieves the same-named part, an error occurs.
Each import statement in this case explicitly references a particular part in a particular package. The part named in such an explicit-type import statement acts as an override of the same-named part in the current package.
If you have identically named packages in two different projects, a given explicit-type import statement uses the EGL build path to do a first-found search, stopping when the required function is found. (The function must be unique to a package in a given project.) The presence of a same-named package in two different projects is not an error, but creates a confusing situation and is not recommended.
An error occurs if you have two explicit-type import statements that name the same part.
Each import statement in this case references all parts in a given package and is called a wild-card import statement.
If you have identically named packages in two different projects, a given wild-card import statement uses the EGL build path to do a first-found search, stopping when the required part is found. (The part must be unique to a package in a given project.)
If more than one wild-card import statement retrieves the same-named part, an error occurs.
When a program is invoked on a call or transfer statement, the argument list of the invoker must match the parameter list of the invoked program. A mismatch of argument and parameter causes an error.