#10987: -i option requires named module -------------------------------------+------------------------------------- Reporter: crockeea | Owner: osa1 Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 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: | -------------------------------------+------------------------------------- Changes (by osa1): * owner: => osa1 Comment: Here's how this works: - When parsing a module, GHC assumes module name is Main if it's not given. (at least in GHCi. relevant code: HeaderInfo.getImports) - When a file or module name is passed, it first tries to disambiguate the string to see if it's a file path or module name. It does this by checking if <argument>.hs or <argument>.lhs exist. (relevant code: GHC.guessTarget) - If it's a file path, `GhcMake.summariseFile` is called. This one makes no assumptions one which module to look for. So this works fine. It doesn't check module name. In the example above, `ghci test/Bar` and `ghci Foo` run this function, because GHC finds `test/Bar.hs` and `Foo.hs` files. - If it's a module name(that is, GHC was unable to find `<argument>.hs`), then `GhcMake.summariseModule` is called. This one assumes that the module name is whatever's passed as argument, so it fails in the example above. `ghci -itest Bar` assumes module name should be `Bar`. `ghci Foo` would do the same, except it can find `Foo.hs` so it runs `summariseFile` which makes no assumptions on module name. One way to fix this is to never guess file names. `ghci Blah` would always look for a module named `Blah`, `ghci Blah.hs` would always look for a file, without any assumptions about which module it has. (To be continued...) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10987#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler