
#10643: GHC cannot import submodules when run from subfolder -------------------------------------+------------------------------------- Reporter: FPtje | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: subfolder Operating System: Unknown/Multiple | import submodule cd Type of failure: GHC rejects | Architecture: valid program | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by svenpanne): I think the current behavior is not silly at all, and the proposed solution will very probably lead to confusion in non-trivial settings: Assume that you have the following directory/file structure: Foo/Yes/A.hs Bar/Yes/B.hs with the same contents as in the OP. GHC(i) can happily load this if you set the right import paths and give the module name, not the file name: {{{ $ ghci -iFoo:Bar Yes.A GHCi, version 7.10.1.20150630: http://www.haskell.org/ghc/ :? for help [1 of 2] Compiling Yes.B ( Bar/Yes/B.hs, interpreted ) [2 of 2] Compiling Yes.A ( Foo/Yes/A.hs, interpreted ) Ok, modules loaded: Yes.A, Yes.B. }}} So the assumption that a module name tells GHC exactly the location of the subfolder is wrong, the import path effectively overlays several directories. This is standard behavior for lots of compilers/interpreters which is needed for more complicated projects, and I don't think we should change that. As it is, it is already complicated enough, putting some "clever" magic into GHC just to avoid a single commandline option is not the way to go. How does your proposal interact with the import path? How can one avoid accidentally finding the wrong module? Should filenames on the commandline be handled differently from module names? IMHO the answers to these questions are far from obvious and the potential gain (saving a single commandline flag) doesn't outweigh the introduced complexity. P.S.: What do you mean by "name inconsistency error"? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10643#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler