#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 RyanGlScott): Replying to [comment:18 goldfire]:
This might be more useful taking a `Name` instead of a `Con`. I imagine it has to just extract the name and look it up anyway, no? Or does it apply the extensions currently enabled to the `Con` definition and report back what GHC would decide if the declaration were given? That seems a bit silly.
You're right, all it does is extract the `Name` and look it up. I opted for `qReifyConStrictness` to take a `Con` instead of a `Name` simply because you'd be less likely to pass it a bad `Name`, but then again, there are several other `Quasi` functions that are easy to pass bad `Name`s, so I'll change the it to `qReifyConStrictness :: Name -> m [DecidedStrictness]` for consistency's sake. To broadly address the rest of your comments: I called `DecidedStrictness` a "special output form" because I don't really feel like the strictness that GHC infers during compilation is comparable to unpackedness/strictness annotations. We ''could'' try to pursue a design where we unify `Bang` with `DecidedStrictness`, i.e., something like this: {{{#!hs data Strict = IsStrict | IsLazy | Unpack -- This must used with !, so it only needs one constructor | NoUnpackIsStrict | NoUnpackIsLazy | NoUnpack | NoAnnotation }}} but I don't feel like this is the right design. Why? 1. The naming just feels downright awkward (which is why I favored splitting it up). 2. There's a major issue with splicing in a datatype constructed from the TH AST. For example, if we splice this: {{{ DataD [] ''T [] [NormalC 'T [(NoAnnotation,ConT ''Int)]] [] }}} and later reify `T`, what would we get back as the strictness of its field? If we get back `NoAnnotation`, we lose the fact that GHC inferred it to be lazy/strict/etc. If we get back, say, `IsLazy`, we lose the fact that there wasn't an annotation in the first place. We could try putting both things in a `Con`, but I can't figure out a way to do it that makes sense. If we include both the user-marked strictness and the GHC-decided strictness information in a `Con`, then how would we splice in the example TH AST written above? {{{ DataD [] ''T [] [NormalC 'T [({- Source -} NoAnnotation,{- Decided -} ???,ConT ''Int)]] [] }}} It is this precisely this scenario where including the GHC-decided strictness seems to fall flat, IMO. Here, you have to put something in `???`'s place which GHC won't use, and even worse, reifying `T` after splicing it would possibly give you back something different in `???`'s place! Maybe there would be a way to make it work, but I can't see it, which is why I felt the most pertinent choice was to make `DecidedStrictness` into something which could only be reified. If you see another way that's more natural, please let me know! -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10697#comment:19 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler