#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