The REPL now adds a module to the policy store when it initializes. This will
allow the REPL to represent configuration as policy later. In addition, the
REPL keeps track of the currently active module. The modules are identified by
the package name.
The package directive causes the REPL to change the currently active module.
This allows the user to effectively 'cd' into packages and reference docs in
that package without a prefix.
The import directive causes the REPL to add the imported package to the
currently active module.
Also, rename REPL state variables to make them private.
Previously, global variable bindings were not propagated to child contexts
during evaluation. For instance:
import req
p :- q
q :- req = true
>> eval(p, {req: true})
In this case, the binding for req would not be available when evaluating the
body of q. As a result, the query would fail.
Now, we maintain two separate sets of bindings: global and local. The global
bindings are automatically propagated to the child context. Locations that
would previously use ctx.Bindings.Get() have been updated to use ctx.Binding()
which consults both the global and local bindings.
This will make it easier to use the REPL inside other projects. Before,
importing the REPL would create a dependency on the runtime which is
problematic due to the use of glog in the server.
Torin Sandall