[GHC] #10697: Change template-haskell API to allow NOUNPACK, lazy annotations

[GHC]

#10697: Change template-haskell API to allow NOUNPACK, lazy annotations
-------------------------------------+-------------------------------------
        Reporter:  RyanGlScott       |                Owner:
            Type:  feature request   |               Status:  patch
        Priority:  normal            |            Milestone:
       Component:  Template Haskell  |              Version:  7.10.1
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:  #5290, #8347      |  Differential Rev(s):  Phab:D1603
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by goldfire):

 Sorry for being late to the conversation here.

 I find the comment:12 proposal to be a bit baroque. Let's examine the
 principles at play:

 1. TH quotes should faithfully turn user-written syntax into the TH AST.
 But it's not obliged to deal with meaningless user-written syntax. Are all
 nine possibilities enumerated in the original post meaningful? I don't
 think so. (Does `{-# UNPACK #-} ~blah` ever make sense?) If it makes the
 design of TH harder, I don't think we need to deal with the non-meaningful
 combinations. But, all else being equal, being able to represent what the
 user wrote is helpful.

 2. Splicing should respect what extensions are on in the splicing module,
 ''not'' the quoting module. When splicing a quote, GHC should behave
 exactly as if the code were copied and pasted from the quote to the
 splice.

 3. Reification, as implemented, is a lie. GHC does not save the actual
 syntax the user wrote and so does a best-effort approximation. It's always
 going to be a bit wrong, at least until we're giving users a `TyCon`
 directly (which I'm not suggesting here).

 In addition to these bedrock principles (which, I'll admit, I've just made
 up on the spot; if we like them, we should enshrine these or something
 similar somewhere), I'd like to add

 4. Reification should behave identically no matter what extensions are
 enabled. Anything else seems doomed to endlessly befuddle users.

 Given these design principles, I favor the original proposal the most.
 It's straightforward enough to programmatically generate, to
 programmatically examine, and for humans to understand.

 I think I favor an implementation of reification that never returns
 `NoStrictAnnot` and never returns `NoUnpackAnnot`; that is, it tells you
 precisely what GHC is doing, all the time. This has the noted downside
 that laziness annotations will cause compilation problems without
 `StrictData`. So we also add new (quite straightforward, pure) functions
 that make a reified data declaration suitable for `-XNoStrictData` or
 `-XStrictData`. Perhaps with Phab:D1200 complete (extension checking), we
 can offer a function that just does the right thing.

 This reification problem is quite similar (as you point out) to kind
 annotations on type variable binders. A few versions ago, reification used
 `PlainTV` for all `*`-kinded variables and `KindedTV` for others. But this
 was just bogus, and now there are a lot more kind signatures. Of course,
 this means that reified code might not always compile if spliced -- just
 like what I'm proposing about strictness, etc.

 What do we think? I have not looked at the implementation, as we haven't
 settled on a design.

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