#7867: Allow template-haskell to communicate with itself between compilation units through the interface file --------------------------+------------------------------------------------ Reporter: errge | Owner: Type: | Status: patch feature request | Milestone: 7.8.1 Priority: | Version: 7.6.3 normal | Keywords: Component: | Architecture: Unknown/Multiple Template Haskell | Difficulty: Easy (less than 1 hour) Resolution: | Blocked By: 3725, 8337, 8340, 8397, 8398 Operating System: | Related Tickets: Unknown/Multiple | Type of failure: | None/Unknown | Test Case: | Blocking: | --------------------------+------------------------------------------------ Comment (by errge): Simon, first of all thanks for your reply. I'll do the wikipage, but in the meantime I'd like to clear up some confusion by answering your specific questions and giving further pointers. * What you miss is that `tcp_connect_timeout` is useful without being exported, because it can be used INSIDE the TCP module. Namely in the `connectToTCP :: Host -> Port -> IO ()` method. That method can simply refer to the current flag value by `flags_tcp_connect_timeout`. The user doesn't have to implement any passing of the value from Main through WGet to TCP, like in other getopt libraries. Please read these for further clarification: 1. http://www.haskell.org/pipermail/haskell- cafe/2012-April/099641.html 2. http://blog.risko.hu/2012/04/ann-hflags-0.html 3. https://github.com/errge/hflags/blob/master/examples/package/test/main.hs, https://github.com/errge/hflags/blob/master/examples/package/TupMain.hs, https://github.com/errge/hflags/blob/master/examples/package/Tup.hs * You're right about qReifyModules, that's maybe the most shaky part of this. I actually don't like the current way how this is handled inside GHC, but I'm quite sure that I don't see enough to judge this. Currently GHC slurps up interface files and then uses them all while compiling different source files with --make. This results in the ill-definedness you are talking about, but this is unfortunately already visible via the TH API, in #8408 I show that with a concrete example. Let's discuss this in #8398, maybe we can come up with a better definition for module listing, I'll give it a try over the weekend to implement a better patch. I'm all in for implementing this feature slowly and cleanly for a future release if not for 7.8, right about that. My end goal is to have the right and general compiler features, so the maintenance burden is minimal on me too regarding hflags and new GHC versions :) On the other hand, I'd really like to have a working hflags as soon as I can: by using dirty tricks internally inside hflags (like communicating via instances instead of annotations). The only missing puzzle piece that I desperatly need support for from the compiler is to make a module orphan from TH. Currently I can do this by generating a fake orphan rule, but that would generate a warning for the user when compiling with -Wall, I'd like to have a warningless way. Can we maybe come up with a design/solution just for #8337 that is small and easy enough to be surely not messed up or regretted later? I still prefer option 1, stating that module anntations make a module orphan seems pretty harmless, but useful from my point of view. The patch would be also some clean and concise. I'll report back here when the more general summarizing wikipage that you asked for is ready and then we can continue to work on the more difficult changes for annotation reification and module listing in a more principled way. Can the already merged patches for #3725 and #8340 stay, please? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/7867#comment:13 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler