Resolving Dependencies Properly

Dependencies cannot be resolved properly without knowing the agent program context in which a module is used. The problem is that actions and predicates that are defined in one agent may not be defined in another agent that is using the same module. It thus depends on the agent that uses the module whether dependency errors should be generated or not.

A New Grammar to Resolve Dependency Issues

A redesign of the grammar is needed to resolve these issues. In particular, a module file should include references to everything it depends on. A module can depend on action specifications (of actions called by rules), other modules (being called as abstract actions in rules), and predicate definitions (used in knowledge, beliefs, goals, rule conditions, or pre- or post-conditions of action specifications that are part of the module). Summarizing, a module file would typically include references to:

• action specifications
• other modules
• knowledge

The easiest way to reference action specifications is to include those in a separate action specification file and refer to that file. An additional benefit of introducing a separate action specification file is that it stimulates re-use. The same action specification file can be used again in another module. Moreover, in principle, skeletons for action specification files that specify actions provided by a specific environment can be automatically derived from that environment. As the pre- and post-conditions of action specifications depend on predicate definitions, an action specification file should include references to:

• knowledge

Although in principle a knowledge file that contains predicate definitions can itself again depend on other knowledge files, it seems not a good choice and not strictly necessary to have knowledge files reference other knowledge files again. The disadvantage would be that a file with a pure knowledge representation syntax would need to allow now also for references to other knowledge files. It seems better to use pure knowledge representation files.

The logic of the set up discussed above, moreover, suggests that there is no need any more for a separate knowledge section in a module. Instead one should simply include a knowledge file. A possible benefit, moreover, would be that the knowledge representation language can be (at least partially) determined from the extension of the file (a Prolog file has extension .pl, etc.).

Finally, the need for a separate agent file also seems to disappear. Whereas an agent file used to be a container for more than one module, it appears to be a better choice to include each module in a separate file, if only to stimulate reuse. All that remains to be specified then, is to indicate which module is used for initialisation, as main module, and as event module. This, however, is perhaps better delegated to the MAS file, where the agentfiles section could be changed into an agents section which defines agents by their name, which module is used as init module (optional), which module is used as main module (required), and which module is used as event module (optional).