[GHC] #10643: GHC cannot import submodules when run from subfolder

[GHC]

#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