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
#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): 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