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

GHC ghc-devs at haskell.org
Thu Dec 10 17:25:07 UTC 2015


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

 > (relatedly I wonder if I can get GHC to tell me what
 strictness/unpackedness is ultimately choosen, as a debugging tool)

 You can, with
 [http://git.haskell.org/ghc.git/blob/f4f00c0f28f3c21eb6f1396f48058c430c4e9b30:/compiler/basicTypes/DataCon.hs#l886
 dataConImplBangs].
 [http://git.haskell.org/ghc.git/blob/f4f00c0f28f3c21eb6f1396f48058c430c4e9b30:/compiler/basicTypes/DataCon.hs#l472
 HsImplBang] only has three possible configurations: `HsLazy`, `HsStrict`,
 and `HsUnpack`. This is more or less what TH tries to do right now, except
 in a half-baked way. For example, if you try to splice in a datatype with
 an argument that is both unpacked and lazy, it will just revert to
 `NotStrict`. (It doesn't take `-XStrict` or `-funbox-strict-fields` into
 account, however.)

 I strongly feel that we need to include both the `HsSrcBang` and
 `HsImplBang` information in Template Haskell (and probably in generics, if
 we fix [https://ghc.haskell.org/trac/ghc/ticket/10716 this issue]).
 Otherwise, we are misleading users. I don't like the idea of having to
 look up whether a dynamic flag is turned on or not (via `isExtEnabled` or
 otherwise) to know for sure what something's strictness is.

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


More information about the ghc-tickets mailing list