[GHC] #9627: Type error with functional dependencies

[GHC]

#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):

 Replying to [comment:4 simonpj]:
 >
 > I think that
 [https://people.cs.kuleuven.be/~tom.schrijvers/portfolio/haskell2017a.html
 Elaboration on functional dependencies] (Karachalias and Schrijvers, 2017)
 does he job nicely.

 Respectfully (to both the authors of the paper and to Simon): I disagree.
 The paper doesn't consider overlapping instances. (Neither did the `FDs
 via CHRs` paper.)

 >  Indeed they use the above example in their motivation section.  It
 describes how to translate fundeps into type families -- so the
 intermediate language is exactly System FC, as today.
 >

 (Yes I linked to the paper in comment:3.) Then how does System FC handle
 overlaps? Does it cope only with Closed Type Families? Then using System
 FC won't work for separate compilation of overlapping instances or
 instances that have the potential for overlap but are non-confluent (ref
 the Users Guide).

 Let me be careful to say that GHC's current implementation of these
 'features' is more by accident than design. They can be used very
 powerfully; they can also very easily lead to incoherence and confusion.
 That's why I ref'd #15632.

 > I never implemented this, but if someone did then fundeps would acquire
 the same expressive power as type families.

 Hmm. There's different interpretations of "expressive power" in play here.
 Thanks to overlaps, I say FunDeps are ''more'' expressive than TFs: then I
 don't want FunDeps to be hobbled.

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