#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): 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. 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] }}}
1. TH quotes should faithfully turn user-written syntax into the TH AST.
But it's not obliged to deal with meaningless user-written syntax. Are all nine possibilities enumerated in the original post meaningful? I don't
Agreed. think so. (Does `{-# UNPACK #-} ~blah` ever make sense?) If it makes the design of TH harder, I don't think we need to deal with the non-meaningful combinations. But, all else being equal, being able to represent what the user wrote is helpful. 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 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. 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.
2. Splicing should respect what extensions are on in the splicing module, ''not'' the quoting module. When splicing a quote, GHC should behave exactly as if the code were copied and pasted from the quote to the splice.
3. Reification, as implemented, is a lie. GHC does not save the actual syntax the user wrote and so does a best-effort approximation. It's always going to be a bit wrong, at least until we're giving users a `TyCon`
Also agreed. I moved the `DecidedStrictness` stuff out of the AST so that this property would be preserved. directly (which I'm not suggesting here). True, but I think that as long as property 2 holds, this isn't a big deal. Not only that, but TH's `SourceStrictness`, `SourceUnpackedness`, and `DecidedStrictness` are in one-to-one correspondence with GHC's `SrcStrictness`, `SrcUnpackedness`, and `HsImplBang`, respectively, so we don't have to lie in this particular case.
4. Reification should behave identically no matter what extensions are enabled. Anything else seems doomed to endlessly befuddle users.
I think I favor an implementation of reification that never returns `NoStrictAnnot` and never returns `NoUnpackAnnot`; that is, it tells you
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,
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. 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). 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. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10697#comment:16 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler