Performance is a central concern of this project. Anything that makes it slower will probably not be adopted. Anything that makes it faster without overly complicating the implementation will be considered. It would be interesting to see how we fare on the standard Prolog benchmarks. Currently, on my machine, solving the classic Zebra puzzle 1000 times takes SWI-Prolog about 6 seconds, it takes core.logic running under Clojure 1.3.0 less than 2s without occurs-check.

If you wish to work through The Reasoned Schemer with core.logic make sure to look over this first.

Contributing

No pull requests please. Please open tickets and submit patches to JIRA

Immediate Roadmap

The following are avenues we are interesting in pursuing now:

Fair Conjunction - currently many finite programs diverge if recursive goals are not carefully ordered. Some work has been done towards guaranteeing termination. Do these changes adversely affect the performance of many useful programs? Is this a non-concern with constraint programming facilities?

Environment Trimming - Definite Clause Grammars (DCGs) are quite slow in miniKanren. This may be due to a lack of groundness analysis or it may be because we are not trimming the environment of needless logic variables. It looks like the original Kanren paper may have some good approaches.

Constraint Logic Programming - Constraint Handling Rules (CHR) is particularly inspiring. William Byrd and Daniel Friedman are working on CLP(FD) and CLP(X) extensions to miniKanren. We should incorporate this.

Groundness Analysis - Initial research on feasibility done. It does in fact give significant performance boosts (2-3X). Seems to close many performance gaps between SWI-Prolog and miniKanren. However maintaining correctness seems difficult. Perhaps limit optimization to DCGs and pattern matching sugar. Again, the original Kanren paper may have insights here.

Unification

core.logic comes with a unifier that can be used much like core.unify:

(unifier '(?x ?y ?z) '(12 ?y)) ; (1 2 _.0)

The above is quite slow since we have to walk the data structure and replace the logic var symbols. It's more efficient to prep the expressions before hand if you're going to be unifying the same expressions over and over again.

It's important to index relationships so that the time to run queries doesn't grow linearly with the number of facts. You can create indexes for any element of the fact tuple. Note that this has implications for memory usage.

YourKit

YourKit has has given me a free license for their profiler, greatly simplifying the profiling of core.logic performance.

YourKit is kindly supporting open source projects with its full-featured Java Profiler. YourKit, LLC is the creator of innovative and intelligent tools for profiling Java and .NET applications. Take a look at YourKit's leading software products:

Notes

I stayed pretty true to the ideas of the original implementation. There are however several key differences. Unification uses protocols in order leverage the full speed of the host. Clojure's cons operator differs significantly from Scheme's so I added the LConsSeq protocol. Sequences which end in a logic variables can be represented by using lcons

(lcons 'a (lvar 'b)) ; (a . <lvar:b>)

Logic variables are instances of LVar not vectors as they are in Scheme.

The goal and goal constructor portion has been written from scratch on top of the protocols and makes liberal use of lazy sequences to prevent stack overflow.

Currently the Substitutions deftype uses clojure.lang.PersistentHashMap internally. This may be replaced with something that provides better performance for triangular substitutions.

Goals

Simplicity. Optimizations should not destroy the ideas behind the original design. Any person willing to take take the time to understand the original Scheme implementation should have little trouble understanding how core.logic is put together.

Performance. This implementation is faster than miniKanren under Racket and seems to be close to performnace of miniKanren recorded by the original designers when running under Chez Scheme.