A clear mechanism to structure large programs, the MINERVA packages allow to

• incrementally compile large programs in units of files
• develop independent program parts with seperate name spaces
• load program parts automatically or on request
• build libraries of programs
• statically check for missing predicates

Motivation

Large programs, teams of several programmers, maintenance needs and software engineering discipline strongly suggest to break down programs into manageable, fairly independent modules.

MINERVA supports this with seperate namespaces and an intelligent loading scheme. This implements dynamically loadable modules while still allowing fairly strict static checks by the compiler.

The overall result is smaller, faster loading and more robust programs.

Principles

The MINERVA compiler minervac produces for each *.min MINERVA source file a *.mpk MINERVA package file with the module interface specification and a *.mbc MINERVA binary code file.

A program can access other packages with the package directive.

Explicitly referenced predicates which are not defined in the own program and not accessible via package directives are flagged by the compiler with an error.

A program exports by default all its predicates.

Predicates starting with the underscore character '_' are not exported to the *.mpk file and not accessible by other packages.

Predicates with identic name/arity exported by several packages are shadowed by the predicate of the first loaded package.

Packages are searched for in the directories and according to the sequence given by the '-sp' parameter of minerva.

Even multiply referenced packages will be loaded only once.

Name spaces of seperate packages are seperate.

Examples

The package "aaa" exports aaa/1, aaa1/1, aaa2/1 but not _aaa3/3.

% file: aaa.min

aaa(C) :-
	aaa1(A),
	aaa2(B),
	'_aaa3'(A,B,C).

aaa1(1).
aaa2(2).

'_aaa3'(A,B,C) :-  C is A + B.

The definiton of bbb/1 uses _aaa3/3 of "bbb". _aaa3/3 of "aaa" is not accessible to "bbb".

% file: bbb.min
:- package(aaa).

bbb(C) :-
	aaa1(A),
	aaa2(B),
	'_aaa3'(A,B,C).

'_aaa3'(_,_,ccc).

%  file:  ccc.min
:- package(bbb).

ccc(C) :-
	aaa(C).

aaa(1).

Programing Recommendations

We recommend:

• to select an expressive name for each package, if possible identic to the most prominent predicate defined by that package. This helps to understand program libraries.
• to mark internal predicates with the leading '_' as non-top-level. This keeps *.pkg files compact and stresses the public predicates as intended for external use.
• to write the package directives at the top of a file. This stresses program dependencies
• to use identic package search paths for both compilation with minervac and execution with minerva or over the net with the *.msp MINERVA Startup Property file.
• to group independent libraries into seperate directories and add these directories to the '-sp' search path option of minerva and minervac as needed.
• to use the '-v' option of minerva to check the loading sequence and timing of packages.
• to use the '-l' option of minerva to force loading at startup time if desired.
• to use the 'load/1' predicate to force loading at run time if desired.
• to use the automatic loading "on demand" mechanism of MINERVA as default