> But that is then no longer a Datalog solver but a "well engineered purpose built solver". I don't really agree. Specialized implementations for instances of

> But that is then no longer a Datalog solver but a "well engineered purpose built solver". I don't really agree. Specialized implementations for instances of a problem that can solved more efficiently than the general case are a pretty fundamental part of any mature solver (GMP is probably the most well-known example). This includes even cases where the user says to try the specialized algorithm and the solver checks that you indeed have an instance of it, rather than the specialized subproblem being automatically detected by the solver (there are many examples, but I always think of optimizations for read only transactions in databases--generally you have to declare the transaction read-only up front). > As for the "built in" part, anything that is not built in must cross an API boundary and usually translate between different data representations. That is a theoretical reason for being slower. The abstractions required for getting solvers to perform well on problems like this are usually sufficiently far removed from the representation you'd have had if you didn't have to solve the problem that (1) transforming it is only a small part of the overall time to solve, and (2) it is often a cost you already have to pay to some extent.