Modularity

Different Vadalog programs represented as modules can be interconnected and thereby form a single Vadalog program which can be evaluated.

@module

This type of annotations defines the name of the module.

@module("moduleName").

@include

This type of annotations defines dependencies between vadalog modules. Each module therefore should be annotated with the @module annotation.

@include("moduleName").

File-based Modularity

The following behaviour is only available via REST endpoint /evaluateFromRepoWithParams.

A special variant of modularity via @module and @include annotations is file-based modules and inclusion. That is, module names defined via @module annotations and used in an @include directive represent file names. Consider the following example:

% File main.vada
@include("/path/to/module_A.vada").

main(X) :- sub_A(X).

@output("main").

The file main.vada resides in the configured repository and includes a module with name /path/to/module_A.vada which at the same time indicates that the module resides in the file /path/to/module_A.vada. The file /path/to/module_A.vada then looks as follows:

% File /path/to/module_A.vada
@module("/path/to/module_A.vada").
@include("/path/to/module_B.vada").

sub_A(1).
sub_A(1).

It has a module annotation, indicating that the module name is equal to the file path which is essential to have the modularity work correctly. It again includes another module /path/to/module_B.vada, besides having facts for the relation sub_A. Note that module inclusion can be seen as content replacement, thus a module can be an arbitrary valid Vadalog program, e.g. a single rule, a collection of facts or a complete program including @output annotations. Note the file paths can either be relative (from where the engine runs) or must be absolute otherwise.