#8489: clean up dependency and usages handling in interface files -------------------------------------+------------------------------------- Reporter: errge | Owner: errge Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Template | Version: 7.7 Haskell | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Moderate (less Unknown/Multiple | than a day) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by errge): Simon, unfortunately this is not done yet and that is totally on me :( The main task here is to "fix TH module reification to reify direct import list, not usages" So just having more comments is not enought, actual coding (and probably some refactoring) has to happen. On the other hand, I am pretty sure that the better comments will help me to get back up to speed more quickly when I sit down to handle this. I still plan to work on this, so feel free to leave me as owner unless someone else wants to tackle this before me in which case I am happy to discuss more if questions come up. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8489#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#8489: clean up dependency and usages handling in interface files -------------------------------------+------------------------------------- Reporter: errge | Owner: errge Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Template | Version: 7.7 Haskell | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Moderate (less Unknown/Multiple | than a day) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by errge): Simon, yes of course, it is important to first agree on what we want. On the other hand, this is a much smaller change than my changes from previous year, so I do not think that we need a whole wiki page again. Let me put it here what I think the issue is and then you can point it out where I was not precise enough and we can complete this to a "specification". Take the following program: {{{#!haskell {-# LANGUAGE TemplateHaskell #-} import Language.Haskell.TH import Language.Haskell.TH.Syntax $(do let mod = Module (PkgName "binary-0.7.1.0") (ModName "Data.Binary") ModuleInfo info <- reifyModule mod runIO $ mapM_ print info return []) main = return () }}} On my machine, the output is: {{{ Module (PkgName "base") (ModName "Data.Either") Module (PkgName "base") (ModName "Data.Maybe") Module (PkgName "base") (ModName "Data.Word") Module (PkgName "base") (ModName "GHC.Base") Module (PkgName "base") (ModName "GHC.IO") Module (PkgName "base") (ModName "GHC.IO.IOMode") Module (PkgName "base") (ModName "GHC.Word") Module (PkgName "base") (ModName "Prelude") Module (PkgName "base") (ModName "System.IO") Module (PkgName "binary-0.7.1.0") (ModName "Data.Binary.Class") Module (PkgName "binary-0.7.1.0") (ModName "Data.Binary.Generic") Module (PkgName "binary-0.7.1.0") (ModName "Data.Binary.Get") Module (PkgName "binary-0.7.1.0") (ModName "Data.Binary.Get.Internal") Module (PkgName "binary-0.7.1.0") (ModName "Data.Binary.Put") Module (PkgName "bytestring-0.10.4.0") (ModName "Data.ByteString") Module (PkgName "bytestring-0.10.4.0") (ModName "Data.ByteString.Lazy") Module (PkgName "bytestring-0.10.4.0") (ModName "Data.ByteString.Lazy.Internal") Module (PkgName "ghc-prim") (ModName "GHC.Types") }}} And looking at http://hackage.haskell.org/package/binary-0.7.1.0/docs/src /Data-Binary.html it can be seen that we do not import GHC.Types in binary. So from the programmer point of view, this change should make the ModuleInfo list returned by module reification only contain the actual direct imports. So this is my goal, before discussing implementation details inside GHC, may I ask if this description is clear enough and if others agree with the goal? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8489#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#8489: clean up dependency and usages handling in interface files -------------------------------------+------------------------------------- Reporter: errge | Owner: errge Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Template | Version: 7.7 Haskell | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Moderate (less Unknown/Multiple | than a day) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by errge): If I remember correctly the difference is not the package boundary, but the compilation unit boundary. So if you compile your modules with different GHC invocations by using -c instead of --make, then you will not have the `usg_exports` either, am I right? If that is the case I prefer us to do the right fix and include this information in the interfaces files and do not introduce different behavior depending on compilation technique in the meantime. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8489#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#8489: clean up dependency and usages handling in interface files -------------------------------------+------------------------------------- Reporter: errge | Owner: errge Type: task | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mgsloan): I don't understand how the explicit imports list of a module would be helpful to another module. I've never grokked the usecase for this. I suggest just changing the documentation to indicate that it is a list of usages rather than imports, to resolve this. How's that sound? Assigning this ticket to myself, to implement via documentation. Alternatively, this usages information could just get removed. Worth checking if there are uses of it on hackage. I am considering implementing reification of exports (https://ghc.haskell.org/trac/ghc/ticket/10391), which is what I think most people would want in module reification as that would be quite useful. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8489#comment:12 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler