Re: [GHC] #9813: Error when reifying type constructor

12 Feb 2016

      #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):

 Excellent points goldfire.

 My thoughts on your three suggestions:

 * A) As you say, declaration order isn't something we normally have to
 consider in Haskell, which is a drawback I hadn't thought about,
 * C) Sounds simple, but seems a little arbitrary that types would be
 available to all splices, but functions only according to the top-to-
 bottom ordering, why should types be more important than terms? :-)
 * B) Certainly sounds simple and using it in my example above,
 {{{exprContainingSplice1}}} and {{{exprContainingSplice1}}} would have
 access to all of {{{A}}},{{{B}}},{{{f}}},{{{g1}}} and {{{g2}}} but ''not''
 each other, which seems very reasonable.

 A question/thought: should {{{reify}}} be able to determine information
 about datatypes/expressions, but have them still be unavailable for
 compile-time evaluation? E.g. consider the following:
     {{{#!hs
 import Language.Haskell.TH

 double :: (Num a) => a -> a
 double x = x * 2

 data D = D Int
        deriving Show

 doReify = do
     print $(reify 'double >>= litE . stringL . show)
     print $(reify 'D >>= litE . stringL . show)

 doEval = do
     print $(litE . integerL $ double 10)
     print $(litE . stringL . show $ D 10)

 main = doReify >> doEval
     }}}
 under the B) suggestion, the following will fail to compile (with a stage
 restriction error) unless the definition and usage of {{{doEval}}} are
 commented out. Is that surprising? Is there a technical reason to rule out
 {{{doEval}}}? The user guide currently has this to say
...
You can only run a function at compile time if it is imported from
 another module. That is, you can't define a function in a module, and call
 it from within a splice in the same module. (It would make sense to do so,
 but it's hard to implement.)
 is this related to why {{{reify myFunction}}} doesn't contain the source
 of {{{myFunction}}} - as per #1831?
--
Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9813#comment:14
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler