[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