[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:31 simonpj]:
 > Yes, this is the main reason for the fairly draconian staging
 restriction at present.  But that's only when you want to RUN a splice.
 If you merely want to reify a type declared "earlier" (as in the
 Description of this ticket), that's much less stressful.  But it exists
 already
 > {{{
 > data F = MkF
 > $(makeLenses 'F)
 > }}}

 Absolutely, since `F` is defined in the ''previous'' declaration group to
 `makeLenses 'F`.

 My proposal is to allow:

 {{{
 data F = MkF
 f x = x
 g = $(mapM reify [''F, 'MkF, 'f] ...)
 }}}

 to work too (i.e. allow access via `reify` to (certain) declarations in
 the ''same'' declaration group).

 Implementation-wise, I can imagine that the changes will be something
 along the lines of:
 1. Partition the expressions in a declaration group into those that
 contain splices, and those that do not,
 1. Make each expression that contains a splice implicitly depend on all
 expressions that do not contain splices,
 1. Traverse the the toposorted dependency graph and mark all nodes below
 or containing a splice as "splicy",
 1. Process all nodes that are not marked splicy,
 1. Make available the information about the non-splicy nodes in the
 environment,
 1. Process all splicy nodes.

 Presumably, much of this can be taken from the code used to implement the
 features pointed out by Simon.

 I will likely start taking a serious look at this tonight. Any
 pointers/suggestions gratefully received!

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