Treat variables in type queries same as type wildcards - #396
Conversation
klntsky
changed the title
|
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 |
|
Hm, I suppose the current handling of |
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
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? |
|
One possible solution is to return negative numbers for exact matches of type constructors: |
|
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). |
A type search for `a -> HTMLElement` previously returned no concrete results where `_ -> HTMLElement` matched functions like `HTMLAnchorElement -> HTMLElement`, because compareTypes had no case for a query-side type variable against a concrete type (#395). Query variables now match any concrete type, as wildcards do, except that each instantiation charges a penalty of 1 - less than a single unit of structural mismatch (10) - so results that unify with the query directly still rank first. Each instantiation is also recorded against the variable's name and fed through typeVarPenalty, so repeated query variables must be instantiated consistently: for the query `a -> a`, `Int -> Int` ranks above `Int -> String`. Existing comparisons are unaffected: no previously-matching clause changed, so current rankings only gain new, lower-ranked results. Also fixes the compareTypes doc examples, which had a typo (parseType s2 twice) and a stale expected score predating the 10x score scaling. Based on #396 by @klntsky.
3 participants
fix #395