[GHC] #9627: Type error with functional dependencies

GHC ghc-devs at haskell.org
Sat Dec 22 02:05:03 UTC 2018


#9627: Type error with functional dependencies
-------------------------------------+-------------------------------------
        Reporter:  augustss          |                Owner:  (none)
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:
       Component:  Compiler (Type    |              Version:  7.8.3
  checker)                           |
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by AntC):

 (This ticket is the main motivation for
 [https://people.cs.kuleuven.be/~tom.schrijvers/Research/papers/haskell2017a.pdf
 this paper].)

 Replying to [comment:1 simonpj]:
 > Indeed.  Here is a more direct example: ...
 > From which we get ...

 What's frustrating in the example is that if we put an equation for `f`
 that gets the code to compile:

 {{{
 f _ = undefined
 }}}

 GHC (8.0 and Hugs way back in 2006) infer `f :: Bool -> Bool`.


 > Remember that GHC elaborates the program into System FC, generating
 evidence.
 >  * For functional dependencies I have no clue what evidence might look
 like.

 The short answer would be: whatever GHC is doing to improve to that
 signature, just make it evidence.

 Perhaps GHC is being cautious about selecting an instance for `C`: the
 wanted is `C Int b`; if it weren't for the FunDep, there could be other
 instances that match that; GHC is undependable in picking instances in
 presence of a dependency #15632. I tried with an instance more like the
 `FDs via CHRs` theory

 {{{
 instance (b ~ Bool) => C Int b
 }}}

 That instance head is exactly the wanted, but GHC gives the same
 behaviour.

 > If someone can explain how to elaborate functional dependencies into
 well-typed evidence in System FC, that would be good.  My inability to do
 so was one of the reasons we developed type families and System FC in the
 first place.
 >

 Aha! Does that "inability" date to before the `FDs via CHRs` 2006 paper?
 (The work on Assoc data types started 2005, that lead on to Type
 Families.)

 * One piece of evidence would be the improvement of the FunDep target
 arising from the constraint `(b ~ Bool)` on my recast instance.
 * One piece would be that that instance head exactly matches the wanted.
 * One piece would be that `~` constraint arises from the FunDep.

 A couple of complications:

 1. There might be multiple FunDeps, say

 {{{
 class C2 a b  | a -> b, b -> a
 }}}

    Then looking for evidence would have to treat instances as if:

 {{{
 instance C2 Int Bool

 instance   (b ~ Bool) => C2 Int b
          | (a ~ Int) => C2 a Bool
          | C2 Int Bool
 }}}

    (That's ''not'' any sort of proposal for syntax. I'm trying to express
 there are pseudo-instances arising from the FunDeps.)

    Those pseudo-instances overlap, but they're consistent with the
 FunDeps, according to the `FDs via CHRs` rules.

 2. Overlapping instances combined with FunDeps are already problematic.
 Again treating the target as a bare typevar with an `~` constraint,
 ''then'' considering overlaps in resulting substitution ordering seems to
 work ticket:15632#comment:2

-- 
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9627#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler


More information about the ghc-tickets mailing list