Earlier quoted context omitted.
Of course you could say it's a subset of unification, as it is. It definitely is, and a limiting one at that. How does Hoon infer the type error in whatever is the Hoon equivalent of the, say, JavaScript expression (a == b && b == 5 && a == "foo"), where a and b are function parameters?
But my previous reply is a little content-free, as what you're really asking for is how we solve the same problem that typeclasses solve in Haskell. Very briefly, there's two ways of asking whether a caller can change the type of a parameter. The normal way is to say, are all the possible values of the caller's type in the set of nouns that the parameter defines? This is what I call "geometric polymorphism." But ther…
If I understand you correctly, what you're calling "geometric polymorphism" is usually called structural typing or subtyping, and what you're calling "generic polymorphism" is usually called duck typing.
Duck typing isn't amenable to static typechecking, so it's not comparable to Haskell's typeclasses.