[GHC] #8776: Displaying pattern synonym for a GADT

[GHC]

#8776: Displaying pattern synonym for a GADT
-------------------------------------+------------------------------------
        Reporter:  monoidal          |            Owner:
            Type:  bug               |           Status:  new
        Priority:  normal            |        Milestone:
       Component:  Compiler          |          Version:  7.7
      Resolution:                    |         Keywords:
Operating System:  Unknown/Multiple  |     Architecture:  Unknown/Multiple
 Type of failure:  None/Unknown      |       Difficulty:  Unknown
       Test Case:                    |       Blocked By:
        Blocking:                    |  Related Tickets:
-------------------------------------+------------------------------------

Comment (by simonpj):

 Gergo writes (to ghc-devs):The problem is that the two type variables
 occurring in the provided context both have "t" as their user-visible
 name; even though the second one is projected as "t1" in the tau type on
 the right-hand side.

 The code to generate this output is in `HsBinds.ppr_sig`, using
 `pprPatSynSig` which just adds the "pattern" keyword and the separating
 "=>" symbols etc:
 {{{
 ppr_sig (PatSynSig name arg_tys ty prov req)
    = pprPatSynSig (unLoc name) False args (ppr ty) (pprCtx prov) (pprCtx
 req)
    where
      args = fmap ppr arg_tys

      pprCtx lctx = case unLoc lctx of
          [] -> Nothing
          ctx -> Just (pprHsContextNoArrow ctx)
 }}}
 My guess is that the problem is `pprHsContextNoArrow` projects individual
 constraints one-by-one and so doesn't notice the name clash on 't' between
 the two constraints in the example; whereas 'ppr ty' walks the whole
 right-hand tau type and thus has the opportunity to maintain a set of type
 variable names used.

 My question is, where is that logic, and how can I use that in this
 instance? My hope is to be shown a design where I can run 'ppr ty',
 'pprCtx prov' and 'pprCtx req' in the same "naming environment" (I hope
 such a thing exists) so that they use a consistent naming scheme. This
 looks like a problem that must have popped up at a lot of places in GHC
 already and must have an idiomatic solution.

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