CategoricalData
Rethink the 'primitive' function variant
Right now, there are three kinds of functions in Hydra's term grammar: lambdas, eliminations, and primitives. The latter is a bit of a misfit, since primitives aren't necessarily functions (e.g. hydra.lib.maps.empty is a nullary constant), and because the same purpose could be served by variable terms -- e.g. instead of function $ primitive hydra.lib.lists.concat, we could just have variable hydra.lib.lists.concat. We will just need to merge the lookup functions for primitives and terms. If anything, there should be a top-level primitive variant which provides direct access to the metadata of the primitive, including its type signature. However, I don't think that is necessary. Probably the best approach is to have the result of a lookup be a union between different entities which can exist in the graph's namespace; you would then pattern match on the union and handle primitives differently than terms.
Note: a side-effect of this change is probably that either the Function or the Elimination type will go away, as Function will otherwise be left with only two variants.
Be sure to resolve #168 before making any changes to Hydra Core. It is best to make sure inference is completely finished, and will not be broken by the removal of the 'primitive' variant.