[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
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 FPtje):

 > With your proposal when your cwd is the top-level "Yes", "ghc A.hs"
 would pick up the file containing Yes.Yes.B, which is not what you want
 I'm not sure what you mean exactly, but I tried this with current ghc, and
 it already does find the module. However, since the Yes/Yes/B.hs contains
 Yes.Yes.B, and A.hs tries to import Yes.B, a module name mismatch error
 occurs (see screenshot: http://i.imgur.com/hQuh8dx.png). It doesn't seem
 like this would be a problem.

 The screenshot also shows that the behaviour is the same when I append the
 search path that I request to be added by default.

 I'm not saying that "." in the search path should be ''replaced'' by my
 proposition, rather, I suggest that a path needs to be added with the
 lowest priority. That way, all previous behaviour should remain unchanged,
 with the exception that it should find modules that it arguably should
 have in the first place.

 '''About why this problem in general should be fixed:'''
 > In any non-toy program, having a single -i option is your least problem,
 so you will have a .cabal file, anyway.

 This issue is generalised to just compiling, because that is where this
 bug lies. The bug makes development a huge nuisance. Personally I like
 working on a single file, having it loaded in ghci. The power of ghci is
 that it can load any single haskell file and work with it, executing
 single functions. However, simply going to the folder containing the
 haskell file, opening up a terminal and running ghci will often have you
 run into this bug, forcing you to either cd to the root folder or give the
 root folder to -i.

 This is annoying, but it also makes writing linters unnecessarily
 difficult. This linter (https://github.com/SublimeLinter/SublimeLinter-
 ghc) for example simply runs ghc -Wall on any haskell file open in the
 Sublime text editor. Since ghc is run from some arbitrary location, it
 gives a meaningless result when it hits this bug. The same happens when
 pressing the "Build" button in sublime, which just runs "runhaskell
 $file".

 The only way for Sublime and sublimelinter-ghc to solve this problem is to
 try to find out the root path of the source and either give that to
 ghc/runhaskell or put that in an -i option. This would involve searching
 for cabal files, parsing haskell files, having the user set it manually or
 other things that go way beyond the idea of ''"tools that run a command on
 a file and show a pretty output in the text editor"''.

 The responsibility of this issue lies with the source of the problem: ghc
 not realising that the source file containing Yes.B might just very well
 be right next to the source file of Yes.A.

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10643#comment:6>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler