#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 | import submodule cd Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rodlogic): It would surprise me, should I see something like the following: {{{ src/Yes/A.hs (module Yes.A ...) src/Yes/B.hs (module Yes.B ...) src/Yes/Yes/B.hs (module Yes.B ...) }}} Maybe the above structure is useful to deal with conditionally compiled modules such as platform specific ones? Or some other use case that can't be achieved with a less surprising structure? Even in those cases why not keep the structure normalized? Such as: {{{ src/Yes/A.hs (module Yes.A ...) src/Yes/B.hs (module Yes.B ...) src/Yes/Windows/B.hs (module Yes.Windows.B ...) }}} Or even a completely separate include path for the platform specific modules assuming the module names don't clash. The above is clearer and simpler to me. That assumes: 1. The module structure must match the file system structure (WYSIWYG) - what is the value we get from this variability here? Another similar example of this is the fact that Cabal doesn't complain that a file {{{../xyz.cabal}}} may have a cabal package named {{{MyYesPackage}}}. 2. No clever nesting of module tree within module tree making thing more complicated. There is probably not much GHC can do here since it is more of a best practice that not everyone may agree with. If we can agree on (1) above, then I find this proposal quite reasonable. As I understand it, this would mean that GHC should be able to infer an include path based on the current module file and that this include path would take precedence over the current path, which seems to be already an implicit include dir (?). I would go even further and have GHC outright reject, or at least warn first then completely reject after a couple of releases, a module structure that doesn't match the file system structure. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10643#comment:13 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler