Treat First-Order Relations as Relation Types

[kyledewey]

Currently first-order relations live in a separate space and don't have types associated with them. For example, consider the following code:

clausedef(foo, [], [int, int]).
foo(5, 6).

Intuitively foo is of type relation([int, int]), though currently this is not correct. We may want to consider this to be true. This avoids highly annoying situations where we have to wrap things inside lambda, as with:

clausedef(increment, [], [int, int]).
increment(X, Y) :-
    Y is X + 1.

clausedef(incrementList, [], [list(int), list(int)]).
incrementList(List, NewList) :-
    % preferable: map(List, increment, NewList).
    map(List,
            lambda([X, Y], increment(X, Y)),
            NewList).

We could also employ currying here, though that may be overkill. To be clear, this situation hasn't come up all too frequently; usually there is at least some change that occurs to at least one of the parameters, which would prevent us from doing this.

[kyledewey]

This is also arguably a bad idea, as it complicates both typechecking and readability. For example, what if increment is also a constructor? In this situation the typing rules become nondeterministic, and some use of things has shown that the existing atom nondeterminism already can make diagnosing type errors a pain. Moreover, this requires knowing what's currently in scope in order to read code, which from the offset we've considered to be a Bad Idea.