[GHC] #14218: GHC.Stack.HasCallStack not compatible with constraint synonyms

[GHC]

#14218: GHC.Stack.HasCallStack not compatible with constraint synonyms
-------------------------------------+-------------------------------------
        Reporter:  ntc2              |                Owner:  (none)
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:
       Component:  Compiler          |              Version:  8.2.1
      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 simonpj):

 It's nothing specific about call-stacks. It's in implicit parameters:
 {{{
 type C2 =  (?x::Int, ?y::Int)

 h1 :: C2 => Int -> IO ()
 h1 v = print (?x+v)

 -- h2 :: (?x::Int, ?y::Int) => Int -> IO ()
 h2 :: C2 => Int -> IO ()
 h2 v = let ?x = 0 in h1 v

 main = let { ?x = 3; ?y = 4 }  in h2 4
 }}}
 This prints 7; but if you swap to the other (equivalent!) type sig for
 `h2` it prints 4 (as it should).

 Reason: in `h2`, when calling `h1` we should really rebuild a pair-
 constraint to pass on to `h1` so that we "see" the binding (which behaves
 like a local instance declaration) for `?x`.  But we don't: we just have a
 wanted constraint `[W] C2` and a given one with the same type, and solve
 one from the other.

 We don't allow implicit parameters as superclasses for exactly this
 reason.  It matters precisely where an implicit parameter constraint is
 solved, so you can't meaningfully abstract over them.

 `HasCallStack` is really just an implicit parameter, so it fails in the
 same way.

 Possible solutions:

 1. Don't allow implicit parameters in type synonyms, or
 2. Expand type synonyms in constraints more aggressively, so they really
 behave ''exactly'' like the expanded version.

 I vote for (2).  Indeed I was surprised that doesn't happen already.

 But I think we should prohibit
 {{{
 type instance F [a] = (?x::a, Show a)
 }}}
 with an implicit parameter on the right.  Now aggressive expansion won't
 always work.  This should be just as illegal as implicit parameters in
 superclasses.

 In effect, implicit parameters aren't really a first-class constraint
 form: you can't abstract over them.

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