[GHC] #11484: Type synonym using -XTypeInType can't be spliced with TH

GHC ghc-devs at haskell.org
Tue Apr 5 07:51:47 UTC 2016


#11484: Type synonym using -XTypeInType can't be spliced with TH
-------------------------------------+-------------------------------------
        Reporter:  RyanGlScott       |                Owner:
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:
       Component:  Template Haskell  |              Version:  8.0.1-rc1
      Resolution:                    |             Keywords:  TypeInType
Operating System:  Unknown/Multiple  |         Architecture:
 Type of failure:  GHC rejects       |  Unknown/Multiple
  valid program                      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by goldfire):

 My guess is that this problem is a consequence of the quite delicate
 design of `TcHsType.splitTelescopeTvs`. I imagine there's a way to apply a
 delicate patch to the delicate algorithm to fix this, but I propose a
 better solution that makes this all more robust: refactor `TcTyCon` to
 store more information about user-written telescopes (that is, lists of
 type variables that may have dependencies) so that `splitTelescopeTvs`
 becomes trivial.

 When I first wrote `splitTelescopeTvs` as part of the `TypeInType` work, I
 hadn't yet added `TcTyCon`, and I was very loathe to put surface-Haskell
 details about a user-written telescope into `TyCon`. But now that we have
 `TcTyCon`s that exist only in the first stages of type-checking, it's more
 reasonable to put in more surface-Haskell information. I think this
 refactoring would be fairly straightforward, but I'm afraid I haven't the
 time to do it myself. Happy to advise if you (for any value of "you") wish
 to take this on. Alternatively, if you want to figure out how to fix this
 particular problem without doing the larger refactor, I'm happy to look at
 that, too.

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


More information about the ghc-tickets mailing list