[GHC] #9813: Error when reifying type constructor

[GHC]

#9813: Error when reifying type constructor
-------------------------------------+-------------------------------------
        Reporter:  owst              |                Owner:
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:
       Component:  Template Haskell  |              Version:  7.8.3
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):  Phab:D1899
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by owst):

 Replying to [comment:39 goldfire]:
 > I was referring to
 [https://github.com/ghc/ghc/blob/master/compiler/rename/RnBinds.hs#L293
 this], which is about dependency analysis on bindings in general, not on
 splices.

 Aha! Incidentally, the line linked is never reached for the failing
 testcase in the original report, since the line above it is where the
 splice is renamed, and the `reify` call fails.

 > See [wiki:TemplateHaskell/BlogPostChanges]. Splices used to be run in
 the typechecker. But that caused #4364. And, sadly, I don't know a way to
 solve #4364 and the current ticket. The plan from comment:32 implicitly
 assumes that deciding that two declarations are mutually recursive is a
 conservative choice, and so we can do it even when we're not sure that the
 declarations are indeed mutually recursive. But #4364 shows us that this
 is not the case -- mutual recursion is ''not'' conservative for type
 declarations. And it isn't really for term declarations either: when
 declarations are mutually recursive, type generalization happens ''after''
 checking the whole group, and so making more definitions think that they
 are mutually recursive potentially reduces that level of polymorphism
 (don't have an example of this intricate interaction to hand, I'm afraid).

 Ah yes, a very good reason to move running of splices to the renamer.
 Thanks for pointing out the relevant ticket!

 > So we seem to be a bit stuck:
 >
 > [...] I'm increasingly worried about the power-to-weight ratio of this
 proposal.
 >
 I agree, you're absolutely right about the power-to-weight ratio; bother!
 :-)

 Oh well, I've tweaked the manual so hopefully there might be a little less
 confusion about what's going on in this situation (and indeed, a pointer
 towards the `$(return [])` workaround).

 I'll try and move onto the next small ticket! Thanks for the discussion on
 this one, goldfire!

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