#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

#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: | -------------------------------------+------------------------------------- Comment (by osa1): Here's one more thing about this issue. In the same layout: {{{ ➜ trac10987 ghci -itest Bar.hs GHCi, version 7.10.2: http://www.haskell.org/ghc/ :? for help <no location info>: can't find file: Bar.hs Failed, modules loaded: none. }}} I'd think this is OK, but the user manuals says: https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/separate- compilation.html#search-path

In --make mode or GHCi, GHC will look for a source file for Foo and arrange to compile it first.

GHC uses the same strategy in each of these cases for finding the appropriate file.

This strategy is as follows: GHC keeps a list of directories called the search path. For each of these directories, it tries appending basename.extension to the directory, and checks whether the file exists. The value of basename is the module name with dots replaced by the directory separator ('/' or '\', depending on the system), and extension is a

... source

extension (hs, lhs) if we are in --make mode or GHCi, or hisuf otherwise.

...

-idirs This flag appends a colon-separated list of dirs to the search path.

From the user manual is seems like GHC should have looked into directories in `-i`. We should either update the user manual or modify GHC. Personally, I think GHC should never use `-i` when looking for files, and it should never look for files unless the input has a file format. Otherwise there'll always be some confusing when a file is found, but module loder could also find the same file, because file loader makes no assumptions on what module to find in the file but module loader makes an assumption about this, leading to different outcomes depending on which one runs. Also, man page says "finding imports" for `-i` and it doesn't say anything about "search path" or how files are searched etc. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10987#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler