Treat variables in type queries same as type wildcards

[klntsky]

fix #395

[hdgarrood]

This change invalidates the above comment, right? Although perhaps the fact that #395 was opened in the first place suggests that having a query of a not match the type Int at all wasn't quite the right approach. How about considering it a match, but applying a larger penalty in this case? Say, 2?

[hdgarrood]

Hm, I suppose the current handling of TypeWildcard doesn't really match up with what the comment says.

[klntsky]

Hm, I suppose the current handling of TypeWildcard doesn't really match up with what the comment says.

I believe the initial idea was that TypeWildcard in a query is a special case and should match any type without additional penalty aside of typeComplexity (typeComplexity is probably here to ensure that less hairy types appear higher in the results).

How about considering it a match, but applying a larger penalty in this case? Say, 2?

A greater penalty leads to this:

.

IMO the penalty for instantiation should be lower than the penalty for generalization. What about multiplying everything by 2 and charging just 1 for instantiation?

[klntsky]

One possible solution is to return negative numbers for exact matches of type constructors:

  go (P.TypeConstructor _ q1) (P.TypeConstructor _ q2) | compareQual q1 q2 = pure (-1)

[klntsky]

As for now I updated the comment to reflect the intention behind the proposed fix (though the best way to resolve the issue is not clear IMO).