Type equality logic is wrong

[acrylic-origami]

The type equality routine inst_subty was initially designed for finding instance methods, which could only be found by type comparison. Now, purebase is designed around the concept of type comparison rather than strict Unique matching because this way the types of built-in classes, especially Monad (and do blocks by association), are correct. Then, it's no longer accurate that a more concrete function is an admissible one. This is due to the interaction between contravariance and higher-rank types, such that something like forall a. (a -> a) -> a will work for a call to (Int -> Int) -> Int, but not (forall a. a -> a) -> b.

In general, this problem is hard. How do we know the variance of an arbitrary type constructor, like (forall a. c a)? How does a vary? Of course, between modules there may be many well-typed functions for callsites too, although outside of matching module names, this problem is unsolvable anyways.

I will admit that this is something of a corner case, as it assumes that there are many functions with the same name and very similar types that would fail this analysis. Even things like Data.Map.{...}.map vs. Prelude.map are different enough in signature for this current test to work at picking them apart.