[GHC] #12787: Weird type constraint with undecidable instances

[GHC]

#12787: Weird type constraint with undecidable instances
-------------------------------------+-------------------------------------
        Reporter:  nome              |                Owner:
            Type:  bug               |               Status:  closed
        Priority:  normal            |            Milestone:
       Component:  Compiler (Type    |              Version:  8.0.1
  checker)                           |             Keywords:
      Resolution:  invalid           |  UndecidableInstances
Operating System:  Linux             |         Architecture:  x86_64
 Type of failure:  GHC rejects       |  (amd64)
  valid program                      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by nome):

 Thank you for the explanations.

 For the record: After some more reading (and a lot more thinking) on this
 topic, I realize that a) type classes are much weirder than I thought, and
 that b) the language and syntax of contexts is pretty misleading. It looks
 as though they're something like type-level guards (i.e. a precondition),
 but they're really constraints on polymorphic types ''resulting'' from
 applying a type class to a type:

 {{{#!hs
 type family constraintPartOfPartialOrd a :: Constraint
 type instance constraintPartOfPartialOrd a = TotalOrd a
 type instance constraintPartOfPartialOrd [a] = Eq a
 }}}
 ... put like this, it's clear why the deduced constraint is always
 `TotalOrd a`. So the instance syntax is really the wrong way around, and
 should instead be something like
 {{{#!hs
 instance PartialOrd a = TotalOrd a =>
     tryCompare x y = Just $ tcompare x y
 }}}
 or maybe
 {{{#!hs
 instance PartialOrd a where
     type constraint TotalOrd a
     tryCompare x y = Just $ tcompare x y
 }}}
 because constraints are "attached" to the value-level part of a type class
 instance in pretty much the same way as
 [https://wiki.haskell.org/GHC/Type_families#An_associated_type_synonym_example
 associated type synonyms].

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