Hello, YuriV, you wrote: YV> Where about it it is possible to read? How it works? It from logical programming. To it years 50 if it is no more. The first time I saw unification in a prologue. The theory can be read, for example, in Wikipedia or in any material on the Prologue. At us it, unfortunately, is not described anywhere. Briefly it is possible to describe unification as very abrupt parttern-matching (). Very abrupt it because the bidirectional. In normal the pattern can have variables compared with any subexpression. Unification admits usage of patterns with variables in both operands. If to set from both sides compatible, but not complete descriptions unification adds both operands. We it for simplification of an output of types. In Nitra special types of characters capable to describe not completely specified types are supported. It something is similar to parameters of types, but instead of (normally designated by identifier T) at us it is possible to set so-called free or partially certain variables of types. We have explicitly certain types where the type and all parameters of types are set by specific types. For example (the pseudocode) further is used: List <int> either: string or: List <KeyValuePair <string, int>> As there are variables of types. We designate their capital letters TYPE_VAR_1, TYPE_VAR_2... Type Variables can be used there where the type is expected. For example, in type parameter: List <KeyValuePair <TYPE_VAR_2, int>> Such type will be unified with any type List <KeyValuePair <..., int>> where instead of... There can be any type, including a type variable. Type variables can be free, connected and partially connected. The free variable is unified with any type including with other variables of type (on figs connected or an Internet). At unification from other free variable both variables become aliases for each other. At unification with the normal type, all places where the variable has been mentioned are replaced with this type. At unification of free variable and partially connected, free becomes an alias for partially connected. So if we have types: List <KeyValuePair <TYPE_VAR_1, int>> List <KeyValuePair <long, TYPE_VAR_2>> Unification of these two types changes variable value of type TYPE_VAR_1 on long, and TYPE_VAR_2 on int, and both types become List <KeyValuePair <long, int>>. If to try to unify incompatible types, for example: Unify (List <KeyValuePair <int, int>>, List <KeyValuePair <long, TYPE_VAR_2>>) there Will be a failure of unification which spoils one of types. But unification can be rolled away or tested. On it unification can be used for check of compatibility of types. Besides Nitra supports unification (more precisely to - and kontr-varintnost at unification). For example, pair of such unifications: Unify (List <KeyValuePair <long, TYPE_VAR_2>>, List <KeyValuePair <long, List <char>>>); Unify (List <KeyValuePair <long, TYPE_VAR_2>>, List <KeyValuePair <long, string>>); Variable TYPE_VAR_2 will contain value IEnumerable <char>, as this type in successors both at List <T> and at a line. Type variables can have so-called restrictions on top and restrictions from below. It allows to work with to/counter-alternativeness. So if the same variable (in the program) is transferred as a function parameter and, in a consequence, is used as returned value, a type variable used for the description of this variable receives restriction from below and on top. As a result of unifier operation the object graph turns out. Each subsequent unification can specify types of other variables. And it is no important in what order variables of types have been created and in what order they were unified. All it allow to unify simply at typification one types with others, and in the end to receive "decision" in the deduced types. We give the library decision which already defines characters for variable types, , the parametrized types, to/counter-alternativeness and uses characters as "constant" types. As on it it is possible to do this expanded decision and type systems of higher orders. The author can create the successor of our unifier and algorithms of unification under the language. Certainly it is possible to use Nitra and at all without unification library. Or to create own analog (if we does not arrange with something).