API design for rule program analyses and/or transformations #611
Description
Besides materialisation, there are many further things that one can do with a given logic program, such as running acyclicity checks #610, but also program transformations of various kinds can be conceived. The common aspect of these actions is that there is a rather large number of them, and that there can always be some more in the future. This raises some software design issues:
- Implementations for the various actions should be as modular as possible, without traces of action-specific code or data in the regular objects.
- It has to be thought through how to make these actions available in the API. Currently, we are having a reasoner object as the main entry point for calling materialisation, but we should not have a method for every possible action in this struct.
- Some way for making such actions accessible through the command-line needs to be designed, again in a somewhat modular fashion.