It strikes me as too bad that this API is so imperative. You can see a pattern over and over in the README where they have `do` blocks, in which they clear some global state (`initialize-prolog`), then add some assertions back into that global state (via side-effectful API calls), and finally run a query (which is implicitly a query on the state that's been built up). Why not represent the knowledge base as a normal Clojure data structure, rather than as the effect of a sequence of API calls? Then it can be passed in by the caller alongside the query, instead of being stored as mutable state.

This isn't just a style thing, either; there are consequences. REPL-driven development loses a lot of its slickness when some expressions can only be eval'd in a special context.

Also, what am I supposed to do if two different parts of my program want to use Clolog? If I'm using Clolog, and one of my dependencies is using it too, will we end up trashing each other's global state? (The case of external dependencies is just an example. Let's say I have an application that sets up the Clolog state and runs a query. Part of the setup involves calls to other parts of my application. At the time the code was written, those other parts didn't use Clolog, but now they do, and there's a bug, because those other parts are trashing the Clolog state that their caller had set up, before it runs its query.) Of course, you could get around this by adding something like a dynamically bound variable that points to the instance of state to use, but at that point you're jumping through hoops to support a subpar (stateful) paradigm that Clojure developers expect to be free of.