Static Analyzer

[G3Kappa]

Currently, all static analysis steps are performed haphazardly by the Compiler library through a variety of graphs.

Ideally all static analysis should be performed by a dedicated object that can be passed around.

This also raises the question of the coupling between Interpreter, Solver and KnowledgeBase. In the interpreted execution model, this makes sense somewhat. But in the executed and compiled models, the solver becomes almost a liability to lug around. Ideally, once cyclic and dynamic goals are compiled properly, the solver will no longer be necessary.

The new model should encompass all three execution modes while providing a clear interface to them, with the static analyzer playing a central role in transitioning from the interpreted to the executed modes.

This issue supersedes #11.

[G3Kappa]

See also #75

[G3Kappa]

Update: interpreted mode is no longer a thing, at all. The old tracer is gone, too.

Optimized and non-optimized modes should still be supported, although the non-optimized mode should be considered a debugging configuration.

Therefore, optimized mode is the de-facto standard mode.

The new tracer should essentially place breakpoints at all call sites that aren't optimized away as dead code. When the VM steps over a breakpoint, it signals a trace event. Handlers can then block this event by e.g. waiting for input. Fundamentally, this is similar to how the old tracer worked, but the difference is that there no longer is a 1:1 mapping between breakpoints and call sites, since optimizations may rewrite the tree substantially.
This difference needs to be explored.

These breakpoints should be eventually integrated with the debugger, as well.