
#10697: Change template-haskell API to allow NOUNPACK, lazy annotations -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: feature request | Status: new 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): What I'm still very unsure about is how we should handle strictness in `reify` versus handling strictness during splicing. When spicing in a data declaration, we should probably interpret it as literally as possible. For example, {{{#!hs [d| data U = U {-# UNPACK #-} Int |] }}} should splice just that, even though GHC would notice that a field is marked `{-# UNPACK #-}` without a strictness annotation, emit a warning, and then change that field to lazy afterwards. (On a side note, TH currently doesn't parse `{-# UNPACK #-}` annotations, but that would be easy to fix.) On the other hand, if we were to define a datatype [http://git.haskell.org/ghc.git/blob/688069ca83e949b9bde9883af7df26114e2f9bc0... like this]: {{{#!hs data T = MkT !Int {-# UNPACK #-} !Int Bool }}} and call `reify ''T`, the strictness annotations would probably be meaningless by themselves. You'd need to know whether `-O`, `-funbox- strict-fields`, and/or `-XStrictData` were enabled to get the full story. I believe this is why internally, GHC distinguishes between [http://git.haskell.org/ghc.git/blob/688069ca83e949b9bde9883af7df26114e2f9bc0... HsSrcBangs] (strictness annotations as the user wrote) and [http://git.haskell.org/ghc.git/blob/688069ca83e949b9bde9883af7df26114e2f9bc0... HsImplBangs] (strictness annotations as GHC interprets them). With TH, we can cheat a little bit by using the [https://phabricator.haskell.org/D1200 forthcoming] `isExtEnabled` functionality to query whether `StrictData` is turned on, but for a [https://ghc.haskell.org/trac/ghc/ticket/10716 similar ticket] involving the ability to lookup strictness via generics, we have no such escape hatch. We should probably come up with a satisfying answer to this question so we can have a uniform treatment of strictness reification. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10697#comment:6 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler