pursuit icon indicating copy to clipboard operation
pursuit copied to clipboard

Treat variables in type queries same as type wildcards

Open klntsky opened this issue 6 years ago • 5 comments

fix #395

klntsky avatar Jul 13 '19 16:07 klntsky

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 avatar Jul 13 '19 17:07 hdgarrood

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

hdgarrood avatar Jul 13 '19 18:07 hdgarrood

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:

2019-07-13-213839_678x937_scrot.

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 avatar Jul 13 '19 18:07 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 avatar Jul 13 '19 18:07 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).

klntsky avatar Jul 15 '19 17:07 klntsky