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

GHC ghc-devs at haskell.org
Sun Dec 13 05:05:49 UTC 2015


#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


More information about the ghc-tickets mailing list