#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