[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 goldfire):

 Replying to [comment:38 owst]:

 > Replying to [comment:37 goldfire]:
 > > In particular, GHC already does dependency analysis and chunking, and
 it would be terribly wrong not to have splicy things depend on everything
 else in the declaration group.
 >
 > I can't actually see that this is true for ''untyped'' splices!

 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.

 >
 > Perhaps the obvious question is: is there a particular reason to run
 untyped splices in the renamer vs the typechecker?

 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).

 So we seem to be a bit stuck:

 * Properly checking for mutual recursion requires that splices be run in
 the renamer.
 * The use of `reify` as proposed here requires that splices be run in the
 typechecker.

 We clearly can't have both. (Note that running the splices twice or
 something silly like that doesn't solve the problem, as the `reify` calls
 in the first run will fail.) I'm quite loathe to introduce something like
 `$$$(...)` to mean an-untyped-splice-that-runs-in-the-typechecker. But I
 could see having a `-frun-splices-in-typechecker` flag that solves this
 ticket but breaks #4364; users would just choose which behavior they
 prefer. (Yes, yes, I know: it would be nice to control this per-splice.
 Perhaps that would be better.) The downside to this approach is that it
 means duplicating much of the infrastructure that runs the splices. How
 bad a burden is this? Hard to know without implementing it.

 One potential problem: we really can't run ''pattern'' splices during
 type-checking, as they bring names into scope. So they would be exempted
 from the new behavior, beguiling users into perpetuity.

 (Red herring alert: Much of
 [wiki:TemplateHaskell/BlogPostChanges#Toostronglytyped] talks about the
 need to run ''quotes'' in the renamer. Anything discussed here would not
 change that behavior. This is only about ''splices''.)

 I'm increasingly worried about the power-to-weight ratio of this proposal.
 Recall that "weight" has two distinct components:
  1. The amount of code (both lines and complexity) that this brings, which
 must be maintained forever.
  2. The amount of cognitive burden this feature places on users trying to
 understand Template Haskell, which would now have two different modes of
 operation, both with very subtle, hard-to-predict consequences.

 I'm certainly not saying "no" to the proposal. But I, personally, would
 need convincing before agreeing to merge. A rising chorus of voices saying
 "I need this feature in order to use Haskell more successfully for my
 business or research" tends to be quite convincing.

 Or perhaps I've entirely mischaracterized the problem and there is an
 easier way to do all this. That would make me happy.

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