New: Build Kanren with Extra Term Predicates/Unifiers

[joshcox]

In light of #3, it's a good time to enhance the unification algorithm. Since I'd obviously like to accept more and more data objects into the unification algorithm (the goal being consumer-provided data objects), I think it makes sense to write a unification algorithm builder function that accepts new term types and term unifiers and builds a unification algorithm that encompasses all.

This should be done in a way that is easily used by the consumer. There are two ways, as I see:

1. The consumer needs to initialize an mk library with a pre-determined set of term types and unifiers.
2. Include term types and unifiers within the state; mk automatically extends its internals to encompass the types/unifiers provided.

I like the idea of storing the term types and unifiers within the state. The consumer passes the extra term types/unifiers via IRunOptions. This would allow consumers to take one state created by an invocation of mk and inject it into another invocation of mk. mk could read that incoming state and use the terms/unifiers to build a unification algorithm that is consistent with the one used to originally build that state. Where I think this breaks down is when there are two states that have identical term types but different unifiers - which unifier should kanren pick?

Because of that one caveat above, I'm thinking about going with #1 up above. Provide some function, buildKanren or so, that takes in extra term types/unifiers and bakes them into a custom kanren implementation.

[jotaf98]

Just to pitch in and say that option 2 seems to come with a lot of weird corner cases when mixing different states, so just picking one world-view for the lifetime of the structures seems like the most sensible solution.