#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 goldfire): Replying to [comment:16 RyanGlScott]:
I will admit that I got a little too ambitious with my proposal in comment:12, which Simon noted. TH splices should never be altered if given "bad" input like what I had proposed. I like Simon's idea of granting the user the ability to reify a constructor's fields' strictness after compilation, which I incorporated in Phab:D1603.
Yes, that may be a good middle ground.
I'll go ahead and post the updated design here so we have a common point
to reference in this discussion. Here is the API that concerns reification of data types, which coincides precisely with the strictness annotations a user writes in source code (i.e., `HsSrcBang`):
{{{#!hs data SourceUnpackedness = NoSourceUnpackedness | SourceNoUnpack | SourceUnpack
data SourceStrictness = NoSourceStrictness | SourceLazy | SourceStrict
data Con = NormalC Name [BangType] | RecC Name [VarBangType] | InfixC BangType Name BangType | ForallC [TyVarBndr] Cxt Con
data Bang = Bang SourceUnpackedness SourceStrictness
type BangType = (Bang, Type) type VarBangType = (Name, Bang, Type) }}}
There is also a similar API for discovering what GHC actually turns
these strictness/unpackedness combinations into after compilation (i.e., `HsImplBang`), which can be affected by `-XStrictData`, `-funbox-strict- fields`, etc.
{{{#!hs data DecidedStrictness = DecidedLazy | DecidedStrict | DecidedUnpack
class Monad m => Quasi m where ... qReifyConStrictness :: Con -> m [DecidedStrictness] }}}
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.
1. TH quotes should faithfully turn user-written syntax into the TH
AST.
Agreed.
But it's not obliged to deal with meaningless user-written syntax. ...
I somewhat disagree here. TH splices should produce syntactically valid
code, but there's no guarantee that code that it will be meaningful. After all, you could conceivably splice in something like `foo :: Maybe -> Maybe`. You're talking about splices; I'm talking about quotes. Yes, splices need to deal with whatever the TH AST provides it, producing compilation errors as appropriate. But I don't think quoting does. For example `[| x $$$ y %%% z |]` fails if `$$$` and `%%%` are both non-fix operators of the same precedence. And the TH AST even has the ability to represent that one! (Via `UInfixE`.) So I maintain that quoting doesn't need to deal with nonsensical code, if that makes things easier.
You're right in that internally, GHC doesn't think all nine combinations
are compatible. In fact, `HsImplBang` only has three combinations: strict, lazy, and unpacked. But the source language is much richer, and it would be difficult to graft `{-# NOUNPACK #-}` and laziness annotations onto Template Haskell without acknowledging that unpackedness annotations and strictness annotations can be used independently of each other in source code. I agree. Especially with the various flags that can affect this behavior.
Not only that, you can't always tell what GHC will produce just from
examining the unpackedness and strictness annotations alone; it's also affected by language extensions, optimization levels, and other inscrutable factors. That's why GHC keeps track of `HsSrcBang` information even after it's determined what the `HsImplBang`s are. If it didn't, there'd be no way things like GHCi could tell you how the original data type was written in source code, since that information could have been distorted.
For these reasons, I feel strongly that we need to be able to express
all combinations of annotations, even if some of them aren't meaningful to GHC. I'm not at all disagreeing here. Just saying that it's not the only option. But perhaps this isn't worth debating, as I do tend to agree that representing the source Haskell straightforwardly works out nicely in this case.
4. Reification should behave identically no matter what extensions are
enabled. Anything else seems doomed to endlessly befuddle users.
I feel like you need to be more specific here before I can respond to
this. Are you referring to reification of what the user ''wrote'', or reification of GHC-specific info that depends on compilation settings? If it's the former, I agree, but not if it's the latter. I'm saying that if I reify `Foo`, I should get the same results no matter what extensions are enabled at the point of reification. Of course, if you change the extensions at `Foo`'s definition site, then that substantively changes the definition of `Foo` and should change the output of reification. I can't distinguish between your two cases, I'm afraid. Reification never promises to get back what the user wrote -- it gives you what GHC knows.
I think I favor an implementation of reification that never returns
`NoStrictAnnot` and never returns `NoUnpackAnnot`; that is, it tells you precisely what GHC is doing, all the time. This has the noted downside that laziness annotations will cause compilation problems without `StrictData`. So we also add new (quite straightforward, pure) functions that make a reified data declaration suitable for `-XNoStrictData` or `-XStrictData`. Perhaps with Phab:D1200 complete (extension checking), we can offer a function that just does the right thing.
Again, are you referring to the source strictness or the GHC-decided
strictness here? If it's the decided strictness, then as you say, it doesn't make sense to return "no strictness". If it's the source strictness, adding a "no strictness" option is, IMO, unavoidable (see my response to point 1). Reification talks about compiled things, not source things. The fact that it returns information using surface syntax is the "lie". So this is GHC- decided strictness.
This reification problem is quite similar (as you point out) to kind
annotations on type variable binders. A few versions ago, reification used `PlainTV` for all `*`-kinded variables and `KindedTV` for others. But this was just bogus, and now there are a lot more kind signatures. Of course, this means that reified code might not always compile if spliced -- just like what I'm proposing about strictness, etc.
Upon further thought, I don't think this comparison is a very good one.
`TyVarBndr` is special because it's possible to write type variables without kind signatures and have GHC infer them; that is, there's a special input form for splicing that never appears in the reified output. Strictness, on the other hand, has special ''output'' forms that should never appear in the spliced input. Going the other way is problematic, and for that reason, I adopted Simon's suggestion of splitting off the `DecidedStrictness` stuff and moving it to a `reifyConStrictness` function. I don't agree here. Strictness does not need to have special output forms. It just needs to use unambiguous forms like (unpacked/strict), (not- unpacked/strict) and (not-unpacked/lazy), and never return that it doesn't know. On the other hand, there are 6 extra input forms. Exactly like `TyVarBndr`. You've chosen to implement this asymmetry by introducing new output forms. The same could have been done for `TyVarBndr`, by never giving kind annotations and instead requiring users to reify type variables to get their kinds. I prefer the current behavior. Might strictness be different? That is, might it be easier to reify strictness instead of include it in reified `Con`s? Perhaps. But it's yet another datatype and yet another function in `Quasi`, when we have the ability to say exactly what we want right in the `Con`. With the right flags set, you could even round-trip the reified `Con`s. To be honest, I don't feel strongly about a special reification function vs. returning the info right in the `Con`. But it does seem to me that this is design choice and is not a forced decision. I favor (weakly) returning the info right in the `Con`, just to lessen the footprint of this feature. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10697#comment:18 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler